High level security requirements

[Ben Stoltz]

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.

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.

As far as the OpenBMC filesystem design, I expect the BMC to follow the
typical sequence for each layer of the boot procedure:
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).

The OpenBMC filesystem and its contents should be verifiable before they
are used. What is the scheme to be employed?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20170211/707ddfbe/attachment.html>