High level security requirements

[Patrick Williams]

Ben,

Thanks for starting the list of items Google is concerned about with
respect to security.  This will certainly help us as was start
implementing the code-update support for the BMC.

With respect to P9 specifics, processor design team and the host
firmware team are not really on this mailing list.  I can try to fill in
details where I know them and am fairly certain the information is
already disclosed, but for others we might need to have a confidential
discussion off list with internal IBM teams.

On Sat, Feb 11, 2017 at 02:26:38AM +0000, Ben Stoltz wrote:
> I still need some background on Power9+OpenBMC and OpenBMC in other systems
> in order to form a solid opinion on system security.
> 
> In the case of P9, I want to validate the SBE OTPROM and SEEPROM before
> deploying to the data center. I'd like to be able to automate that
> procedure and run it for any racked system at any time.

OTPROM stands for "one-time programmable ROM".  This is effectively a
set of fuses in the chip that are blown at module manufacturing time
by setting a specific voltage pin at a higher voltage level and
running a programming procedure.  Once this is done it cannot be done
again and, at least how it was for P8, the systems do not even have the
correct voltage level to do the programming outside of manufacturing.

I'm not sure what facilities exist to even read the OTPROM.  I also
don't know how you would get, from IBM, the correct image or a hash
of the image or whatever.  I suspect the image may change over time to
make minor adjustments without a new chip revision or chip part number.
(We need to follow up off-list for this one).

You and I have discussed the SEEPROM previously.  There may be ways to
configure the chip so that the BMC can read the contents out.
Witherspoon is not designed for this; Zaius might need a design change
to facilitate.  I suspect the host firmware team will need to make
changes to the SEEPROM layout to separate out code from data so the BMC
could verify.

> See https://cloud.google.com/security/security-design/ for some publicly
> available information and context. At the lowest level:
> "...We also design custom chips, including a hardware security chip that is
> currently being deployed on both servers and peripherals. These chips allow
> us to securely identify and authenticate legitimate Google devices at the
> hardware level. ..."
>
> Any P9 or OpenBMC security solution should be a very strong story,
> independent of additional measures employed by any particular vendor. The
> threat model should be clearly stated and be specific about what is in and
> out of scope.

Generally speaking, for P8/P9, the security model is that the BMC
protects the BMC and the Host protects the Host and neither trust each
other.  This is how the Power chips are designed from a security
perspective and it certainly fits some vendor's use cases and maybe not
others (apparently yours for sure).

My understanding is that on many x86 servers the BMC is effectively
optional and on some servers the host can even begin booting in parallel
with the BMC.  The BMC might not even have a physical connection to the
flash module containing the BIOS.

We are certainly open to a configuration option controlling:
    * Does the BMC manage the Host flash?
    * If the BMC has access to the Host, does it perform any type of
      verification?

> As far as the OpenBMC filesystem design, I expect the BMC to follow the
> typical sequence for each layer of the boot procedure:

Does "layer" in this context mean u-boot, kernel, userspace on the BMC
or does it mean BMC, Host, ...?  If you mean u-boot, etc. I suspect not
all of these in your can be done by every layer.  (How does u-boot check
for a pending update?)

> 1) check for pending update and update if needed and valid
> 2) remove the ability to update
> 3) copy code and configuration into place for execution
> 4) validate code and configuration
> 5) record measurement or equivalent operation for the system
> 6) transfer control to next layer
> 7) next layer does its work including progression to its subsequent layer
> 
> The BMC, even though it runs Linux, is a fixed stack and has lower overall
> complexity than the host system. Ideally, the BMC can re-enforce the chain
> of trust of the host. In particular, I'm looking to the BMC to close the
> possible gap in the SBE OTPROM and SEEPROM which could otherwise harbor a
> persistent attack (e.g. load HB, validate it, maliciously patch it, run it).

I think we're going to have to talk in detail on the specifics of P9 on
this list and paragraph.  I don't know how the BMC could remove the
ability to update the SEEPROM because the P9 host firmware certainly
needs the ability to write portions of it.  Otherwise, someone would
need to port a significant amount of SBE update code from P9 host to the
BMC and figure out how to feed it with all of the appropriate data.
That means, just as one particular but complicated aspect, the BMC using
FSI to read all of the DIMM SPD, determine the desired DDR frequency,
and calculate the P9 nest internal frequency and update the SEEPROM with
this.

At a basic level, having the BMC verify PNOR contents can be done.  We
do not plan to do this for Witherspoon but we are trying to organize the
code-update and host flash management implementation in a way that this
could be straight-forwardly extended by someone motivated to do so.

> The OpenBMC filesystem and its contents should be verifiable before they
> are used. What is the scheme to be employed?

Rick did work for u-boot and kernel to use FIT signing.  We have not
determined what to do for the userspace rofs yet.  We are using squashfs
today and that will likely stay the same.  I suspect either FIT,
dm-verify, or IMA could be used, each with their own set of trade-offs.

As of right now, we do not have verification high enough on the IBM
team's priority for Witherspoon for Google's Zaius timeline.

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