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

[Yael Kalka]

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