[Fwd: [openib-general] OpenSM and Wrong SM_Key]

Hal Rosenstock halr at voltaire.com
Sun Dec 4 09:11:36 PST 2005 

Hi Yael,

On Sun, 2005-12-04 at 07:10, Yael Kalka wrote:
> Hi Eitan, Hal,
>
> 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).

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