Re: Restricting HOST flash access on OpenBMC

[Benjamin Herrenschmidt <benh@kernel.crashing.org>]

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