Restricting HOST flash access on OpenBMC

Restricting HOST flash access on OpenBMC

[Cyril Bur]

Hello,

Apologies, I have been working on this in a bit of a silo and I suspect
a lot of people will be interested to know this work is going on.

The aim of my work is to provide a simple interface for the host and
the BMC to talk in order for the BMC to give controlled access to the
flash.

At the moment, the BMC maps the host LPC bus to point to the PNOR
directly. This may be undesirable and presents security concerns. If
the host can be taught to request access to the flash then the BMC
could map the LPC bus into a region of its RAM and (depending on
policy) writes wouldn't get propagated to the actual flash. Policy
details are for later.

I developed a simple protocol to allow this exchange of information
documented in the README.md file of the userspace test daemon I wrote
to proof of concept this: https://github.com/cyrilbur-ibm/mboxbridge/tr
ee/newio I will no doubt move this somewhere more suitable in due
course.

I chose to use the MBOX registers on the BMC as they provide a fast
method of data transfer and can raise interrupts on both the host and
BMC.

The aim of sharing this now is to show that the interface works and
that implementation independent things can start to be integrated into
skiboot and linux. Having said that, I would appreciate any feedback, I
have had my head in this for quite some time please let me know if I've
missed something.

The implementation is only a proof of concept, some details still need
to be worked out, especially what happens on BMC reboot. I believe the
interface is ok in that respect, just my implementation which is
lacking.

Do try it out if you want. Of course changes need to be made to the BMC
kernel as well as skiboot:
https://github.com/cyrilbur-ibm/linux/tree/newio
https://github.com/cyrilbur-ibm/skiboot/tree/newio

Thanks,

Cyril

Re: Restricting HOST flash access on OpenBMC

[Rick Altherr]

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

How does this work on non-LPC platforms?

On Sun, Nov 20, 2016 at 8:50 PM, Cyril Bur <cyrilbur@gmail.com> wrote:

> Hello,
>
> Apologies, I have been working on this in a bit of a silo and I suspect
> a lot of people will be interested to know this work is going on.
>
> The aim of my work is to provide a simple interface for the host and
> the BMC to talk in order for the BMC to give controlled access to the
> flash.
>
> At the moment, the BMC maps the host LPC bus to point to the PNOR
> directly. This may be undesirable and presents security concerns. If
> the host can be taught to request access to the flash then the BMC
> could map the LPC bus into a region of its RAM and (depending on
> policy) writes wouldn't get propagated to the actual flash. Policy
> details are for later.
>
> I developed a simple protocol to allow this exchange of information
> documented in the README.md file of the userspace test daemon I wrote
> to proof of concept this: https://github.com/cyrilbur-ibm/mboxbridge/tr
> ee/newio I will no doubt move this somewhere more suitable in due
> course.
>
> I chose to use the MBOX registers on the BMC as they provide a fast
> method of data transfer and can raise interrupts on both the host and
> BMC.
>
> The aim of sharing this now is to show that the interface works and
> that implementation independent things can start to be integrated into
> skiboot and linux. Having said that, I would appreciate any feedback, I
> have had my head in this for quite some time please let me know if I've
> missed something.
>
> The implementation is only a proof of concept, some details still need
> to be worked out, especially what happens on BMC reboot. I believe the
> interface is ok in that respect, just my implementation which is
> lacking.
>
> Do try it out if you want. Of course changes need to be made to the BMC
> kernel as well as skiboot:
> https://github.com/cyrilbur-ibm/linux/tree/newio
> https://github.com/cyrilbur-ibm/skiboot/tree/newio
>
> Thanks,
>
> Cyril
> _______________________________________________
> openbmc mailing list
> openbmc@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/openbmc
>

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

Re: Restricting HOST flash access on OpenBMC

[Benjamin Herrenschmidt]

On Mon, 2016-11-21 at 09:47 -0800, Rick Altherr wrote:
> How does this work on non-LPC platforms?

A different mechanism such as IPMI can still be used on these.

This is basically a replacement for the code we have today which
uses a backdoor into the BMC address space to directly manipulate
the flash controller from the host.

That current mechanism is tricky, causes us to have at least 4 copies
of the whole flash controller driver, and relies on a backdoor that
we would like to close.

In the grand scheme of things, you can see this as an "accelerated"
path to the flash for platforms that have an AST BMC on LPC, but you
can still fallback to something like IPMI if that path isn't
available.

Cheers,
Ben.

> On Sun, Nov 20, 2016 at 8:50 PM, Cyril Bur <cyrilbur@gmail.com>
> wrote:
> > Hello,
> > 
> > Apologies, I have been working on this in a bit of a silo and I
> > suspect
> > a lot of people will be interested to know this work is going on.
> > 
> > The aim of my work is to provide a simple interface for the host
> > and
> > the BMC to talk in order for the BMC to give controlled access to
> > the
> > flash.
> > 
> > At the moment, the BMC maps the host LPC bus to point to the PNOR
> > directly. This may be undesirable and presents security concerns.
> > If
> > the host can be taught to request access to the flash then the BMC
> > could map the LPC bus into a region of its RAM and (depending on
> > policy) writes wouldn't get propagated to the actual flash. Policy
> > details are for later.
> > 
> > I developed a simple protocol to allow this exchange of information
> > documented in the README.md file of the userspace test daemon I
> > wrote
> > to proof of concept this: https://github.com/cyrilbur-ibm/mboxbridg
> > e/tr
> > ee/newio I will no doubt move this somewhere more suitable in due
> > course.
> > 
> > I chose to use the MBOX registers on the BMC as they provide a fast
> > method of data transfer and can raise interrupts on both the host
> > and
> > BMC.
> > 
> > The aim of sharing this now is to show that the interface works and
> > that implementation independent things can start to be integrated
> > into
> > skiboot and linux. Having said that, I would appreciate any
> > feedback, I
> > have had my head in this for quite some time please let me know if
> > I've
> > missed something.
> > 
> > The implementation is only a proof of concept, some details still
> > need
> > to be worked out, especially what happens on BMC reboot. I believe
> > the
> > interface is ok in that respect, just my implementation which is
> > lacking.
> > 
> > Do try it out if you want. Of course changes need to be made to the
> > BMC
> > kernel as well as skiboot:
> > https://github.com/cyrilbur-ibm/linux/tree/newio
> > https://github.com/cyrilbur-ibm/skiboot/tree/newio
> > 
> > Thanks,
> > 
> > Cyril
> > _______________________________________________
> > openbmc mailing list
> > openbmc@lists.ozlabs.org
> > https://lists.ozlabs.org/listinfo/openbmc
> > 
>