OpenBMC Image Management

Stewart Smith stewart at
Mon Jan 30 16:47:13 AEDT 2017

Patrick Williams <patrick at> writes:
> On Wed, Jan 25, 2017 at 05:50:46PM -0600, Chris Austen wrote:
>> "openbmc" < at> 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
>       functionality.  
>         * 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
needed here.

>         * 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 :)

Stewart Smith
OPAL Architect, IBM.

More information about the openbmc mailing list