validating secure boot settings

validating secure boot settings

[Andrew Geissler]

IBM has a feature[1] they’d like in regards to validating secure boot settings. 

The basic requirement is to utilize the new bmc-secure-boot GPIO defined
within this patch[2]. If the GPIO is found, then verify the system is in secure
mode by validating the GPIO reads 1. If it’s not a 1, then log an error.

Similarly the code will also look at a sysfs file created via this patch[3] to tell
if the system was started with secure boot enabled in the firmware. An error
will be logged if it was not.

From an IBM perspective, we only want to run these tests if we’re in what
we consider to be the manufacturing environment. What we use to determine
that will probably be something configurable with the code. There are a lot
of other things that will prevent a boot if the system has secure boot enabled
and the security checks fail. This new function is just a mechanism to
provide a quick check to our manufacturing team that they’ve enabled
everything as expected.

So, anyone else interested in something like this? If so, any votes on where
a good place for this logic to reside would be? We don’t have any obvious
security repository that I can find that seems like a good fit for this.

[1]: https://github.com/ibm-openbmc/dev/issues/3462
[2]: https://github.com/openbmc/docs/commit/d55349e10ec2432886b26b00322ef0eaff2b919a
[3]: https://lore.kernel.org/all/20220204072234.304543-1-joel@jms.id.au/

Thanks,
Andrew

Re: validating secure boot settings

[Richard Hughes]

On Mon, 21 Feb 2022 at 18:23, Andrew Geissler <geissonator@gmail.com> wrote:
> So, anyone else interested in something like this? If so, any votes on where
> a good place for this logic to reside would be?

This seems like the kind of thing that we'd be interested in for the
HSI specification[1], although I appreciate that's only tangentially
OpenBMC related.

Richard

[1] https://fwupd.github.io/libfwupdplugin/hsi.html

Re: validating secure boot settings

[Joel Stanley]

Hi Richard,

Long time listener, first time caller. I appreciate all the work you
do with fwupd.

On Mon, 21 Feb 2022 at 19:49, Richard Hughes <hughsient@gmail.com> wrote:
>
> On Mon, 21 Feb 2022 at 18:23, Andrew Geissler <geissonator@gmail.com> wrote:
> > So, anyone else interested in something like this? If so, any votes on where
> > a good place for this logic to reside would be?
>
> This seems like the kind of thing that we'd be interested in for the
> HSI specification[1], although I appreciate that's only tangentially
> OpenBMC related.

You might be interested in this patch set which Andrew's mentioned:

 https://lore.kernel.org/all/20220204072234.304543-1-joel@jms.id.au/

The idea is to have a set of sysfs files that say "this machine has
secure boot enabled", and other interesting bits about firmware boot
state.

You might already have that on EFI systems, but this would be
consistent regardless of the firmware used. Reading through your HSI
spec, we could also hook up the "read only SPI descriptor" file. I
called that opt_write_protect in an earlier version of my patches.

I have been chatting with Arnd about how to get it merged, and have
some ideas that I'll send out in a v4.

One thing we want to get right before merging is coming up with names
that are meaningful outside of a single firmware (eg EFI) or SoC
vendor (Like the ASPEED names I started with). I welcome your input.

Cheers,

Joel

Re: validating secure boot settings

[Joel Stanley]

On Mon, 21 Feb 2022 at 18:23, Andrew Geissler <geissonator@gmail.com> wrote:
>
> IBM has a feature[1] they’d like in regards to validating secure boot settings.
>
> The basic requirement is to utilize the new bmc-secure-boot GPIO defined
> within this patch[2]. If the GPIO is found, then verify the system is in secure
> mode by validating the GPIO reads 1. If it’s not a 1, then log an error.
>
> Similarly the code will also look at a sysfs file created via this patch[3] to tell
> if the system was started with secure boot enabled in the firmware. An error
> will be logged if it was not.
>
> From an IBM perspective, we only want to run these tests if we’re in what
> we consider to be the manufacturing environment. What we use to determine
> that will probably be something configurable with the code. There are a lot
> of other things that will prevent a boot if the system has secure boot enabled
> and the security checks fail. This new function is just a mechanism to
> provide a quick check to our manufacturing team that they’ve enabled
> everything as expected.
>
> So, anyone else interested in something like this? If so, any votes on where
> a good place for this logic to reside would be? We don’t have any obvious
> security repository that I can find that seems like a good fit for this.

In the future we will have applications that deal with TPM logs and
attestation. This is a precursor to that.

Names that come to mind are:

 - firmware
 - boot
 - information
 - state
 - verification

firmware-state?
boot-information?

And we like putting phosphor at the start, so throw that in.

Cheers,

Joel