OpenBMC Image Management
stewart at linux.vnet.ibm.com
Mon Jan 30 16:47:13 AEDT 2017
Patrick Williams <patrick at stwcx.xyz> writes:
> On Wed, Jan 25, 2017 at 05:50:46PM -0600, Chris Austen wrote:
>> "openbmc" <openbmc-bounces+austenc=us.ibm.com at lists.ozlabs.org> wrote on
>> 01/25/2017 04:15:27 PM:
>> Are there any security goals that need to be considered?
> There are a few different aspects to security that I can think of:
> 1. Is there a way to identify and reject an invalid image (Define
> "invalid") before it is applied onto the system?
> 2. Is there a way to identify an applied image has been tampered with?
> 3. Is there a way for an image to expose a security flaw in the code
> itself (such as by "fuzzing") to cause unintended effects?
I think the biggest opportunity for fuzzing and security analysis will
be in BMC<->HOST interfaces.
It'd be great if every BMC<->HOST interface could be fuzzed in sim or in
> A few statements to answer your question:
> * If there is a fundamental flaw in any of these regards with our design,
> we would like to know about it and will fix it.
> * #1 is typically solved through image signing and a one-time
> verification at the time an image is applied. Issue
> openbmc/openbmc#356 is meant to implement this and would be a
> later feature on top of Adriana's proposed work.
> * #2 is typically solved through "Secureboot" or similar
> * The Power9 processor can implement Secureboot itself, so the IBM
> team currently has no plans to implement additional per-use
> verification of the Host firmware contents [in PNOR] by the BMC.
> * IBM also does not currently plan to include BMC Secureboot for
> the Witherspoon machine's initial delivery.
dm-verity (a device-mapper target taht cryptographically verifies each
filesystem block) could be a way to very easily get most of what's
> * Rick Altherr from Google has been contributing support for
> U-Boot "FIT" images, which provide something like Secureboot
> verification for the kernel and initramfs images.
Combined with dm-verity, we'd be a long way towards a remotely
trustworthy BMC (well, trust-worthy in the way that it's running a
*known* set of vulnerabilities :)
OPAL Architect, IBM.
More information about the openbmc