OEM i2c over IPMI

OEM i2c over IPMI

[Patrick Venture]

We have a linux kernel driver for i2c-via-ipmi that ties into
https://gerrit.openbmc-project.xyz/12604 - I'm putting this upstream
but since it's an IPMI OEM handler, it can nicely go into its own
repository - I was curious if there was any OpenBMC interest?  If so,
we can aim for the phosphor namespace, otherwise I'll just ask that it
be pushed into a google repo.

Thoughts?
Patrick

RE: OEM i2c over IPMI

[Tanous, Ed]

> -----Original Message-----
> From: openbmc [mailto:openbmc-
> bounces+ed.tanous=intel.com@lists.ozlabs.org] On Behalf Of Patrick
> Venture
> Sent: Tuesday, October 2, 2018 1:00 PM
> To: OpenBMC Maillist <openbmc@lists.ozlabs.org>
> Subject: OEM i2c over IPMI
> 
> We have a linux kernel driver for i2c-via-ipmi that ties into
> https://gerrit.openbmc-project.xyz/12604 - I'm putting this upstream but
> since it's an IPMI OEM handler, it can nicely go into its own repository - I was
> curious if there was any OpenBMC interest?  If so, we can aim for the
> phosphor namespace, otherwise I'll just ask that it be pushed into a google
> repo.
> 

What does this command do that the existing master write-read command (section 22.11 of the IPMI spec) doesn't?

I know on past systems we've offered the OEM I2C command to get around the 8 channel limit for the stock command.  I can't tell if that's the case with this one, but we should probably have a statement on exactly what we're trying to solve compared to the IPMI master write read.

It should also be noted that master write-read opens up some pretty scary security scenarios, especially when done over IPMI.  We should probably make sure it's isolated to its own library so the high security systems can opt out of it if need be.

-Ed

Re: OEM i2c over IPMI

[Patrick Venture]

+peterh@

I believe it was a more flexible approach.

Patrick
On Tue, Oct 2, 2018 at 3:39 PM Tanous, Ed <ed.tanous@intel.com> wrote:
>
> > -----Original Message-----
> > From: openbmc [mailto:openbmc-
> > bounces+ed.tanous=intel.com@lists.ozlabs.org] On Behalf Of Patrick
> > Venture
> > Sent: Tuesday, October 2, 2018 1:00 PM
> > To: OpenBMC Maillist <openbmc@lists.ozlabs.org>
> > Subject: OEM i2c over IPMI
> >
> > We have a linux kernel driver for i2c-via-ipmi that ties into
> > https://gerrit.openbmc-project.xyz/12604 - I'm putting this upstream but
> > since it's an IPMI OEM handler, it can nicely go into its own repository - I was
> > curious if there was any OpenBMC interest?  If so, we can aim for the
> > phosphor namespace, otherwise I'll just ask that it be pushed into a google
> > repo.
> >
>
> What does this command do that the existing master write-read command (section 22.11 of the IPMI spec) doesn't?
>
> I know on past systems we've offered the OEM I2C command to get around the 8 channel limit for the stock command.  I can't tell if that's the case with this one, but we should probably have a statement on exactly what we're trying to solve compared to the IPMI master write read.
>
> It should also be noted that master write-read opens up some pretty scary security scenarios, especially when done over IPMI.  We should probably make sure it's isolated to its own library so the high security systems can opt out of it if need be.
>
> -Ed

Re: OEM i2c over IPMI

[Peter Hanson]

[-- Attachment #1: Type: text/plain, Size: 2430 bytes --]

On Tue, Oct 2, 2018 at 8:31 PM Patrick Venture <venture@google.com> wrote:

> +peterh@
>
> I believe it was a more flexible approach.
>
> Patrick
> On Tue, Oct 2, 2018 at 3:39 PM Tanous, Ed <ed.tanous@intel.com> wrote:
> >
> > > -----Original Message-----
> > > From: openbmc [mailto:openbmc-
> > > bounces+ed.tanous=intel.com@lists.ozlabs.org] On Behalf Of Patrick
> > > Venture
> > > Sent: Tuesday, October 2, 2018 1:00 PM
> > > To: OpenBMC Maillist <openbmc@lists.ozlabs.org>
> > > Subject: OEM i2c over IPMI
> > >
> > > We have a linux kernel driver for i2c-via-ipmi that ties into
> > > https://gerrit.openbmc-project.xyz/12604 - I'm putting this upstream
> but
> > > since it's an IPMI OEM handler, it can nicely go into its own
> repository - I was
> > > curious if there was any OpenBMC interest?  If so, we can aim for the
> > > phosphor namespace, otherwise I'll just ask that it be pushed into a
> google
> > > repo.
> > >
> >
> > What does this command do that the existing master write-read command
> (section 22.11 of the IPMI spec) doesn't?
>

Kernel driver provides host side proxy for BMC bus. As such, it supports
*general* multi-step smbus/i2c transfers. E.g., pmbus devices with variable
read length.


> > I know on past systems we've offered the OEM I2C command to get around
> the 8 channel limit for the stock command.  I can't tell if that's the case
> with this one, but we should probably have a statement on exactly what
> we're trying to solve compared to the IPMI master write read.
>

Example use case: detect a card type, then instantiate implied Linux I2C
devices on the associated proxy bus for smbus to that slot.

Yes, also smashes 8 bus limit.


> > It should also be noted that master write-read opens up some pretty
> scary security scenarios, especially when done over IPMI.  We should
> probably make sure it's isolated to its own library so the high security
> systems can opt out of it if need be.
>

Oh, indeed! Should be restricted. (Root on local host, perhaps?) Suggest to
make it opt-in. With red hazard label if that can be done ;^)

Another down-side: i2c/smbus is already flakey and error prone in
interesting scenarios. (Something going wrong, trying to figure out what.)
Adding another protocol layer in the middle can hurt stability.

Arguably most useful as a bridging/prototyping tactic; then moving
interesting accesses into BMC for better stability at volume.


> > -Ed
>

[-- Attachment #2: Type: text/html, Size: 3738 bytes --]