Security Working Group meeting - Wednesday February 2

[Andrew Jeffery]

On Thu, 3 Feb 2022, at 07:51, Joseph Reynolds wrote:
> On 2/1/22 9:24 PM, Joseph Reynolds wrote:
>> This is a reminder of the OpenBMC Security Working Group meeting 
>> scheduled for this Wednesday February 2 at 10:00am PDT.
>>
>> We'll discuss the following items on the agenda 
>> <https://docs.google.com/document/d/1b7x9BaxsfcukQDqbvZsU2ehMq4xoJRQvLxxsDUWmAOI>, 
>> and anything else that comes up:
>
> Attended: Joseph, Jiang, Dick, Michael Richardson, Daniil, Surya, James, 
> Dhananjay
>
> Note that we started on topic 1 (RoT), and then covered topic 3 (CNA) 
> before returning to topic 1.  Topic 2 (NoAccess users) was not covered.
>
>
>>
>> 1. followup from previous meeting: OpenBMC’s AST2600 RoT work 2. 
>> discuss the concept and need for NoAccess users and how they would be 
>> different from disabled BMC user accounts
>
> 1 followup from previous meeting: OpenBMC’s AST2600 RoT work is here 
> https://gerrit.openbmc-project.xyz/c/openbmc/openbmc/+/49789 
> <https://gerrit.openbmc-project.xyz/c/openbmc/openbmc/+/49789>with the 
> underlying OE/bitbake recipe here: 
> https://github.com/openbmc/openbmc/blob/master/meta-aspeed/classes/socsec-sign.bbclass 
> <https://github.com/openbmc/openbmc/blob/master/meta-aspeed/classes/socsec-sign.bbclass>.  
> Note OTP refers to one-time programmable memory used to set the signing 
> key, etc.  Also I (Joseph Reynolds) believe the AST2600 specs are not 
> public domain.

There's another related patch in-flight that adds the OTP configuration 
for p10bmc. It might be a helpful reference. The only thing I'd ask is 
that people use big-endian mode for their keys (which isn't what has 
happened with p10bmc):

https://gerrit.openbmc-project.xyz/c/openbmc/openbmc/+/50716

SOCSEC_SIGN_ENABLE: command not found
Other than that the only thing that's required is setting  in the 
machine configuration, e.g:

https://github.com/openbmc/openbmc/blob/bb99d22ecef61f3af21290b1e1ead3083f25d20f/meta-ibm/conf/machine/p10bmc.conf#L56

>
> …  and general  OpenBMC Root of Trust (RoT) discussion
>
>
> DISCUSSION:
>
> Secure boot trust chain: the BMC hardware performs secure boot of the 
> bootloader (e.g., U-Boot, then U-Boot verifies 
> {kernel,devicetree,rootfs}, etc., up to starting the application.
>
>
> Secure boot has three layers: 1 hardware validates uboot, 2 U-Boot 
> validates the Readonly fs, 3 the operation system validates applications.

This is close but could be more general and more precise:

1. The hardware loads loads the bootloader and validates its signature
2. The bootloader loads the kernel and validates its signature
3. The kernel locates the rootfs and uses a mechanism to verify its 
integrity

Mapping that to the AST2600, we have:

1. The ROM code loads the u-boot SPL into SRAM and validates its 
signature using the public keys from the OTP

2. The SPL loads the u-boot FIT image into DRAM and validates the 
configuration signatures over the hashes of the embedded images using 
the keys residing in the SPL image

3. u-boot loads the kernel FIT image into DRAM and validates the 
configuration signatures over the hashes of the embedded images using 
keys residing in the u-boot image

4. The kernel locates the rootfs and uses a mechanism to verify its 
integrity

> To validate before starting applications:  DMverity, IMA
>
>
> The OpenBMC project is working to support the first layer, specifically 
> AST2600 secure booting U-Boot.  The intention is then to support U-Boot  
> securely booting the next layer (kernel, etc.)  

Again, not quite true.

It's already the case that the SPL validates u-boot and u-boot 
validates the kernel where signing for each is enabled.

Again, leaning on p10bmc as a reference, this scheme is enabled here:

https://github.com/openbmc/openbmc/blob/bb99d22ecef61f3af21290b1e1ead3083f25d20f/meta-ibm/conf/machine/p10bmc.conf#L39-L40

The patches linked earlier add the hardware root-of-trust support 
(generating the AST2600 OTP image and signing the SPL in a manner that 
can pass verification using the OTP image).

> Also there is interest 
> in using DMverity and IMA, but no agreements.

dm-verity is conceptually simpler than IMA, but has limitations that 
IMA can help overcome, so as you say, at least from IBM's perspective, 
we're still working through the details here.

> Does BMC download applications as part of its intended operation?  
> Different use cases.
>
> In the base use case, the BMC read only file system has all 
> applications.  Only developers (and advanced diagnostics) download code, 
> presumably to test fixes or collect more diagnostic data.
>
> Use cases include both validating the filesystem which has the code, and 
> validating the app itself as it is loaded (exec’d) into a Linux process.

If no modifications are made to the filesystem then validating the 
integrity of the filesystem is the same as validating the integrity of 
the application. However in the face of run-time modifications to the 
filesystem, IMA's design helps prevent arbitrary code execution by 
enabling policies such as "any exec'ed file must have a valid 
signature". Trying to enforce a signed execution environment in the 
face of mutable filesystems is hard with dm-verity.

Andrew