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

Hal Rosenstock halr at voltaire.com
Mon Dec 5 03:19:21 PST 2005 

On Mon, 2005-12-05 at 02:52, Eitan Zahavi wrote:
> > >
> > > 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.

Yes, that's what I mean/meant.

-- Hal

> > 
> > 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