add support for Secure Boot #3097

Signed-off-by: Ben Cressey <[email protected]>

For the EFI build, the Secure Boot config signing key is embedded into the GRUB image so that GRUB can verify the signature of any files it loads, e.g. its configuration. By default, the public key is embedded into a section alongside various executable GRUB modules. This set of patches instead moves the key into its own dedicated section in the image, where it can easily be replaced with tools such as objcopy or dd to reuse a set of binary artifacts with different Secure Boot keys. Signed-off-by: Markus Boehme <[email protected]>

shim expects to find an SBAT section in GRUB, and will not continue booting if it is missing. Bottlerocket's build of GRUB is downstream from Amazon Linux, which is downstream from Fedora and RHEL. However, most of GRUB's modules are not included in the BIOS and EFI images, and the configuration file built into the image disables loading any other modules. Hence it's not a given that vulnerabilities in either upstream should lead to SBAT-based revocations. Bottlerocket carries quite a few out-of-tree patches which add the `gpt` and `gptprio` modules, and consequently has an unenviable, but useful, claim to its own vendor entry. Clearly the vast majority of GRUB development happens elsewhere, and the use of a distro-specific vendor entry is not meant to imply otherwise. There are no current plans for Bottlerocket to participate in the wider ecosystem of Secure Boot for Linux distributions, by way of a Microsoft-signed shim, so the choice of SBAT metadata is not relevant elsewhere. Signed-off-by: Ben Cressey <[email protected]>

Build the GRUB EFI image with the modules needed for GPG signature verification, and embed a large placeholder public key so it can be replaced in the final stage of the build. Signed-off-by: Ben Cressey <[email protected]>

The newly added replace-grub-pubkey script allows to replace the public key embedded in a GRUB image. After replacing the key, the image will be properly signed again. Example invocation: ./replace-grub-pubkey grubx64.efi new-grub.pubkey ~/bottlerocket/sbkeys/local/ The script assumes that new-grub.pubkey is a public key file in GPG format containing a single public key. Signed-off-by: Markus Boehme <[email protected]>

shim will now be used as the first-stage bootloader on EFI platforms, and will handle part of the Secure Boot verification chain when that feature is enabled. Adjust the macros used by the grub package so that shim runs first, and finds GRUB with the expected filename. Signed-off-by: Ben Cressey <[email protected]>

Add a large placeholder certificate to the shim binary to facilitate replacement in the final stage of the build. Note that shim is used as the first-stage UEFI bootloader for all variants, but only enforces Secure Boot if the relevant EFI variables are set, and will not use the vendor certificate otherwise. Signed-off-by: Ben Cressey <[email protected]>

For Secure Boot, various certificates, keys, and configuration files are needed to sign binaries and register images. Provide two scripts to simplify the process of generating the correct artifacts. The "local" version of the script is only meant for non-production use, for example by individual developers or by automated CI testing, where the variant builds must support the feature but do not need to be maintained indefinitely. The "aws" version of the script expects various AWS resources such as private CAs and managed keys to be available. This can be costly and only makes sense for official builds of supported variants. Signed-off-by: Ben Cressey <[email protected]>

Ensure that at least one Secure Boot profile is always available, for cases where the variant has Secure Boot enabled. This uses the "local" version of the script, since locally generated keys cost nothing and are guaranteed to be available. This is similar to the locally generated keys used by default for TUF repositories, in that neither is suitable for long-term production use. The individual Secure Boot profile and the directory where profiles are stored can both be overridden, so that profiles can be stored in a different location, such as another Git repository. Profiles are checked for completeness, to allow the expected files to evolve over time, for example to add support for a new platform that expects EFI variables in a different format. Signed-off-by: Ben Cressey <[email protected]>

`buildsys` needs to pass through files from the Secure Boot keys profile in order to sign artifacts during the variant build step. Those files might include an `aws-kms-pkcs11` configuration that uses KMS for signing, which requires network access to be enabled for variant builds. On an EC2 instance, credentials from IMDS will be used automatically by `aws-kms-pkcs11`, but otherwise they need to come from environment variables or an AWS CLI configuration file. Accordingly, `buildsys` now passes the most important of these AWS environment variables as additional secrets. Signed-off-by: Ben Cressey <[email protected]>

Secure Boot is incompatible with existing variants, so a feature flag is required to conditionally enable it. Signed-off-by: Ben Cressey <[email protected]>

To support Secure Boot on VMware ESXi, the OVF templates need to be configured for UEFI boot, and contain placeholders for EFI variables to be populated at build time. Signed-off-by: Ben Cressey <[email protected]>

When Secure Boot is enabled for the variant, ensure that EFI binaries and the GRUB configuration are signed with the expected keys, and replace the placeholder certificates and keys with the right ones. When building an OVA, populate the template with the EFI variable data. Because GRUB will have an embedded GPG public key in this mode, it will automatically verify the detached signature for every file read. This is the desired behavior for `grub.cfg`, which contains sensitive parameters like the dm-verity root hash. However, it's redundant with the EFI binary verification performed by the shim verifier. It would also prevent reading the "initrd" that contains the Boot Config data for kernel command line parameters, because this is generated on the local system and cannot be signed by a trusted key. Since this is the only remaining file to read that is not an EFI binary, it's OK to disable signature checking inside the verified `grub.cfg`. Have GRUB reboot if the kernel cannot be loaded, and backstop this by blocking edits to menu entries with an empty superusers group. This prevents runtime modifications to the expected configuration, which could otherwise be used to alter the dm-verity root hash. Signed-off-by: Ben Cressey <[email protected]> Signed-off-by: Markus Boehme <[email protected]>

If Secure Boot is enabled for the variant, AMIs should be registered with the UEFI boot mode along with the relevant EFI variable payload. Signed-off-by: Ben Cressey <[email protected]>

Secure Boot can't be added in a backwards-compatible way to existing variants without breaking the downgrade path, but will be the default for all newer variants. To ensure the functionality is exercised, set the Secure Boot feature flag in the *-dev variants, which are not intended for production use and do not support downgrades. Signed-off-by: Ben Cressey <[email protected]>

Signed-off-by: Ben Cressey <[email protected]>

Both new options are meant to help with Secure Boot testing. The `firmware-code` option allows a custom edk2 build to be used, for example with aarch64 where the AAVMF build packaged by Fedora doesn't have the Secure Boot feature available. The `firmware-vars` option populates the initial firmware variables from a different file, and sets it to the correct size for aarch64. Signed-off-by: Ben Cressey <[email protected]>

Document the goal and chain of trust for Bottlerocket's Secure Boot implementation. Mention the Lockdown feature, since it's now enabled for all current variants with the exception of `*-nvidia`. Update the metal provisioning guide with a section on how to enable Secure Boot. Signed-off-by: Ben Cressey <[email protected]>

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

add support for Secure Boot #3097

add support for Secure Boot #3097

Commits on Jul 13, 2023