BMC Image Signing Proposal

Stewart Smith stewart at linux.vnet.ibm.com
Tue Jan 30 15:47:02 AEDT 2018


Andrew Jeffery <andrew at aj.id.au> writes:
> On Fri, 2018-01-26 at 14:07 +0300, Alexander Amelkin wrote:
>> Hi, Anoo!
>> 
>> The thoughts are as follows:
>> 
>> 1. BMC usually runs in a secured environment where probability of 
>> tampering with flash IC contents by means other than BMC's firmware 
>> itself is negligible.
>
> This does bring up the issue of developing a threat model to develop
> against; we should probably do that. However, without one, I feel like
> we should design *for* defense in depth and allow people to remove
> protections as they see fit for their environment, rather than make
> potentially compromising assumptions about what that environment is at
> the outset.
>
> For instance, whilst BMCs might typically be isolated from customer
> traffic on a separate LAN, there's still the in-band interface which
> can be used to poke at the BMC. Vulnerabilities in the IPMI stack could
> lead to BMC compromise and undesirable flash writes*. Therefore BMC
> flash integrity remains a valid concern despite network isolation.
>
> * This ties into Michael Brown's talks of isolating daemons to their
> own user/group and enforcing SELinux policy against them.

using isolation technologies that are used by containers may also add
extra depth, and be a good interim solution as SELinux policy is
developed and tuned.

>> 2. U-Boot already performs image checksum validation before booting a 
>> FIT image
>
> Typically the rootfs is not part of the FIT, so it will not be checked.
>     Some systems supported by OpenBMC directly mount the rootfs rather
> than booting through an initrd, which makes rootfs authentication
> somewhat tricky. Regardless, with signed images we should expand the
> FIT hash check to be a full signature check.

dm-verity would solve that (for a ro rootfs). The read/write parts will
have to be carefully controlled of course, noexec is an obvious
thing. Oh, and not having configuration as executable code and being
*paranoid* about parsing config.

-- 
Stewart Smith
OPAL Architect, IBM.



More information about the openbmc mailing list