OpenBMC Image Management

[Patrick Williams]

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?

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.
        * 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.
        * The project would certainly be interested in further
          development here, but hopefully like most of our features, it
          can be selectively enabled or disabled for different machines.
          In particular, given that Power9 is itself performing
          verification of images, verification of the PNOR by the BMC
          should be a choice by the vendor weighing boot-speed and
          security.
        * Adriana is not intending on doing anything explicit to enable
          or impede enablement of this.  If there is something in the
          design or implementation that would significantly impede
          enablement, or if there is a relatively minor improvement that
          can be done to aid future enablement, we are very interested
          in this feedback.

    * We don't intend to have purposeful flaws in the area of #3 (does
      anyone?).  No one has committed to doing explicit penetration
      testing here, but we certainly will accept vulnerability reports
      and, even better, fixes.

-- 
Patrick Williams
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Digital signature
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20170126/91b7f1f5/attachment.sig>