[Fwd: [openib-general] OpenSM and Wrong SM_Key]
Eitan Zahavi
eitan at mellanox.co.il
Sun Dec 4 23:52:21 PST 2005
> >
> > I agree that currently we do not have an authentication mechanism,
> > thus - we cannot decide that an SM is not trusted.
> > I think that in the current situation the option of always sending
our
> > true SM_Key when receiving SMInfo SubnGet request is a good one.
> > In this case - there is no need to update anything in the SMInfo
SubnGet
> > request.
> > Any objections?
>
> IMO this is a first step (assuming in subnet with only OpenSMs and
hence
> all are trusted). What needs to be done is:
> The SM needs a way to know whether the other SM(s) (and which ones)
are
> trusted or not so the SM_Key can be filled in. To accomplish this,
> OpenSM needs to have a list of trusted SMs (e.g. additional
> configuration).
[EZ] I guess what you mean is that a list of trusted SM's port guids
will provided to the SM? We can do that.
>
> Also, given that the current default SM Key is 0. there is no
difference
> here (so perhaps the default SM Key should be changed to a non 0
value).
> There is some ambiguity in the spec currently around this (and a
comment
> has been filed with the MgtWG on this).
>
> -- Hal
>
> > Yael
> >
> >
> > -----Original Message-----
> > From: Hal Rosenstock [mailto:halr at voltaire.com]
> > Sent: Thursday, December 01, 2005 7:02 PM
> > To: Eitan Zahavi
> > Cc: Yael Kalka; openib-general at openib.org
> > Subject: RE: [Fwd: [openib-general] OpenSM and Wrong SM_Key]
> >
> >
> > Hi Eitan,
> >
> > On Thu, 2005-12-01 at 10:35, Eitan Zahavi wrote:
> > > Hi Yael,
> > >
> > > As I read through the MgtWg mails I get the impression that an out
of
> > > spec mechanism is required to know if the other SM is trusted.
> >
> > Yes, that was what I was proposing (in
> > http://openib.org/pipermail/openib-general/2005-December/014186.html
> > where I wrote "The SM needs a way to know whether the other SM(s)
(and
> > which ones) are trusted or not so the SM_Key can be filled in."):
that
> > OpenSM have a list of trusted SMs and OpenSM would use that
information.
> >
> > > In that case and since OpenSM does not currently provide any such
> > > mechanism, I would prefer never to send out the SM_Key on the
request
> > > and always send zero. Sending our SM_Key to a non - trusted SM is
not
> > a
> > > good idea in my mind.
> > >
> > > OpenSM behavior should be to always trust any other SM.
> >
> > Above you said no other SM was trusted so do you mean not trust
rather
> > than trust other SMs ?
> >
> > > So any discovered SM that deserves to be the master should be
granted
> > > that right.
> >
> > Only if it were trusted and had the correct SM Key.
> >
> > -- Hal
> >
> > > Eitan Zahavi
> > > Design Technology Director
> > > Mellanox Technologies LTD
> > > Tel:+972-4-9097208
> > > Fax:+972-4-9593245
> > > P.O. Box 586 Yokneam 20692 ISRAEL
> > >
> > >
> > > > -----Original Message-----
> > > > From: Yael Kalka
> > > > Sent: Thursday, December 01, 2005 2:17 PM
> > > > To: 'Hal Rosenstock'; Eitan Zahavi
> > > > Cc: openib-general at openib.org
> > > > Subject: RE: [Fwd: [openib-general] OpenSM and Wrong SM_Key]
> > > >
> > > > Hi Hal, Eitan,
> > > > I think the best option is to add an OpenSM option flag -
> > > exit_on_fatal.
> > > > This flag can decide on the action on fatal cases:
> > > > 1. Exit or not when seeing SM with different SM_Key.
> > > > 2. Exit or not when there is a fatal link error (e.g - multiple
> > > guids).
> > > > etc.
> > > >
> > > > I tried to run 2 SMs just now with different SM_keys, and I see
that
> > > none of them
> > > > exit, since both receive SM_Key=0 on SMInfo GetResp.
> > > > The reason for that is that in the SMInfo Get request (as in all
> > other
> > > requests)
> > > > we do not send anything in the mad data. Meaning - all fields
are
> > > clear.
> > > > In the __osm_sminfo_rcv_process_get_request function we are
checking
> > > the state
> > > > according
> > > > to the payload data. This is always zero! Thus - SM will never
know
> > > that the SMInfo
> > > > request is sent from an SM that is master.
> > > >
> > > > I will work on a fix for that.
> > > > Yael
> > > >
> > > > -----Original Message-----
> > > > From: Hal Rosenstock [mailto:halr at voltaire.com]
> > > > Sent: Wednesday, November 30, 2005 11:57 PM
> > > > To: Yael Kalka; Eitan Zahavi
> > > > Cc: openib-general at openib.org
> > > > Subject: [Fwd: [openib-general] OpenSM and Wrong SM_Key]
> > > >
> > > >
> > > > Hi Yael & Eitan,
> > > >
> > > > Based on the recent MgtWG discussions, are you still holding
your
> > > > position in terms of exiting OpenSM when a non matching SM Key
is
> > > > discovered ? Just wondering if I can issue a patch for this and
> > clear
> > > > this issue so OpenSM can be compliant for this aspect. Thanks.
> > > >
> > > > -- Hal
> > > >
> > > > -----Forwarded Message-----
> > > >
> > > > From: Hal Rosenstock <halr at voltaire.com>
> > > > To: openib-general at openib.org
> > > > Subject: [openib-general] OpenSM and Wrong SM_Key
> > > > Date: 08 Nov 2005 16:08:47 -0500
> > > >
> > > > Hi,
> > > >
> > > > Currently, when OpenSM receives SMInfo with a different SM_Key,
it
> > > exits
> > > > as follows:
> > > >
> > > >
> > > > void
> > > > __osm_sminfo_rcv_process_get_response(
> > > > IN const osm_sminfo_rcv_t* const p_rcv,
> > > > IN const osm_madw_t* const p_madw )
> > > > {
> > > > ...
> > > >
> > > >
> > > >
> > > > /*
> > > > Check that the sm_key of the found SM is the same as ours,
> > > > or is zero. If not - OpenSM cannot continue with
> > configuration!.
> > > */
> > > > if ( p_smi->sm_key != 0 &&
> > > > p_smi->sm_key != p_rcv->p_subn->opt.sm_key )
> > > > {
> > > > osm_log( p_rcv->p_log, OSM_LOG_ERROR,
> > > > "__osm_sminfo_rcv_process_get_response: ERR 2F18: "
> > > > "Got SM with sm_key that doesn't match our "
> > > > "local key. Exiting\n" );
> > > > osm_log( p_rcv->p_log, OSM_LOG_SYS,
> > > > "Found remote SM with non-matching sm_key.
Exiting\n"
> > );
> > > > osm_exit_flag = TRUE;
> > > > goto Exit;
> > > > }
> > > >
> > > > C14-61.2.1 states that:
> > > > A master SM which finds a higher priority master SM with the
wrong
> > > > SM_Key should not relinquish the subnet.
> > > >
> > > > Exiting OpenSM relinquishes the subnet.
> > > >
> > > > So it appears to me that perhaps this behavior of exiting OpenSM
> > > should
> > > > be at least contingent on the SM state and relative priority of
the
> > > > SMInfo received. Make sense ? If so, I will work on a patch for
> > this.
> > > >
> > > > -- Hal
> > > >
> > > >
> > > > _______________________________________________
> > > > openib-general mailing list
> > > > openib-general at openib.org
> > > > http://openib.org/mailman/listinfo/openib-general
> > > >
> > > > To unsubscribe, please visit
> > > http://openib.org/mailman/listinfo/openib-general
More information about the general
mailing list