Chapter 5. Configuring RHEL on AWS with Secure Boot

1. Initialization: When a RHEL instance boots, the cloud-hosted firmware initially boots and implements the Secure Boot mechanism.
2. Variable store initialization: The firmware initializes UEFI variables from a variable store. This is a dedicated storage area for information that firmware needs to manage the boot process and runtime operations. When the RHEL instance boots for the first time, the store initializes from default values associated with the VM image.

3. Boot loader: When booted, the firmware loads the first stage boot loader. For the RHEL instance in a x86 UEFI environment, the first stage boot loader is shim. The shim boot loader authenticates and loads the next stage of the boot process. It acts as a bridge between UEFI and GRUB.

   1. The shim x86 binary in RHEL is signed by the Microsoft Corporation UEFI CA 2011 certificate.
   2. RHEL instances use the shim binary to boot in the Secure Boot-enabled mode on various hardware and virtualized platforms.
   3. Check that the platform has the default Microsoft certificates in its Allowed Signature database (db).
   4. The shim binary extends the list of trusted certificates with Red Hat Secure Boot CA and optionally, with Machine Owner Key (MOK).

4. UKI: The shim binary loads the RHEL UKI (the kernel-uki-virt package). The corresponding certificate, Red Hat Secure Boot Signing 504 on the x86_64 architecture, signs the UKI.

   1. You can find this certificate in the redhat-sb-certs package. Red Hat Secure Boot CA signs this certificate, so the check succeeds.
5. UKI add-ons: When using UKI cmdline extensions, the RHEL kernel verifies their signatures against db, MOK, and shim certificates. This process ensures that either the operating system vendor, RHEL, or a user has signed the extensions.

Prerequisites

1. You have installed the following packages on the RHEL instance:

   • awscli2
   • python3
   • openssl
   • efivar
   • keyutils
   • edk2-ovmf
   • python3-virt-firmware

2. You have verified that the RHEL AMI has the uefi-preferred option enabled in boot settings:

   $ aws ec2 describe-images \
   --image-id ami-0a951f007be151ff9 \
   --region us-east-2 \
   | grep -E '"ImageId"|"Name"|"BootMode"'

   "Name": "RHEL-10.1.0_HVM-20260217-x86_64-0-Hourly2-GP3",
   "BootMode": "uefi-preferred",
   "ImageId": "ami-0a951f007be151ff9",

   Warning

   Store your private keys separately from the RHEL instance where you use them. If an intruder gains access to the instance, they could use the stored secrets to escalate their privileges and compromise your system security.

3. You have verified the platform status of the RHEL Marketplace AMI instance:

   $ sudo mokutil --sb-state

   SecureBoot disabled
   Platform is in Setup Mode

   The setup mode allows updating the Secure Boot UEFI variables within the instance.

Procedure

1. Generate a custom_db.cer custom certificate:

   $ openssl req -quiet \
   -newkey rsa:3072 \
   -nodes -keyout custom_db.key \
   -new -x509 -sha256 \
   -days 3650 \
   -subj "/CN=Signature Database key/" \
   --outform DER -out custom_db.cer

2. Generate UEFI variables file by using the virt-fw-vars utility:

   $ virt-fw-vars --enroll-redhat \
   --add-db-cert OvmfEnrollDefaultKeys custom_db.cer \
   --set-dbx /usr/share/edk2/ovmf/DBX* \
   --output-auth .

   For details, see the virt-fw-vars(1) man page on your system.

3. Convert Public Key (PK) variable to the Extensible Firmware Interface (EFI) Signature List (ESL) format:

   $ tail -c +41 PK.auth > PK.esl

   Note

   Each GUID is an assigned value and represents an EFI parameter:

   • 8be4df61-93ca-11d2-aa0d-00e098032b8c: EFI_GLOBAL_VARIABLE_GUID
   • d719b2cb-3d3a-4596-a3bc-dad00e67656f: EFI_IMAGE_SECURITY_DATABASE_GUID

   The EFI_GLOBAL_VARIABLE_GUID parameter maintains settings of the bootable devices and boot managers, while the EFI_IMAGE_SECURITY_DATABASE_GUID parameter represents the image security database for Secure Boot variables db, dbx, and storage of required keys and certificates.

4. Transfer the database certificates to the target instance, use the efivar utility to manage UEFI environment variables.

   1. To transfer Key Exchange Key (KEK.auth), enter:

      $ sudo efivar -w -A 0x67 -n 8be4df61-93ca-11d2-aa0d-00e098032b8c-KEK -f KEK.auth

   2. To transfer allowed signature database (db.auth), enter:

      $ sudo efivar -w -A 0x67 -n d719b2cb-3d3a-4596-a3bc-dad00e67656f-db -f db.auth

   3. To transfer forbidden signature database (dbx.auth) for x64 architecture, enter:

      $ sudo efivar -w -A 0x67 -n d719b2cb-3d3a-4596-a3bc-dad00e67656f-dbx -f dbx.auth

   4. To transfer PK.esl, enter:

      $ sudo efivar -w -n 8be4df61-93ca-11d2-aa0d-00e098032b8c-PK -f PK.esl

5. Reboot the instance from the AWS console.

Procedure

1. Generate a custom certificate custom_db.cer:

   $ openssl req -quiet \
   -newkey rsa:3072 \
   -nodes -keyout custom_db.key \
   -new -x509 -sha256 \
   -days 3650 -subj "/CN=Signature Database key/" \
   --outform DER -out custom_db.cer

2. Use the virt-fw-vars utility to generate the aws_blob.bin binary file from keys, database certificates, and the UEFI variable store:

   $ virt-fw-vars --enroll-redhat \
   --add-db-cert OvmfEnrollDefaultKeys custom_db.cer \
   --set-dbx /usr/share/edk2/ovmf/DBX* \
   --output-aws aws_blob.bin

   The customized blob consists of:

   • Public Key (PK.cer), Key Exchange Key (KEK.cer), allowed signature database (db), and forbidden signature database (dbx) from the edk2-ovmf package
   • custom_db.cer the generated certificate

3. Use the awscli2 utility to create and register the AMI from a disk snapshot with the required Secure Boot variables:

   $ aws ec2 register-image \
   --name rhel-10.0-secure-boot \
   --architecture x86_64 \
   --virtualization-type hvm \
   --root-device-name "/dev/sda1" \
   --block-device-mappings "{\"DeviceName\": \"/dev/sda1\",\"Ebs\": {\"SnapshotId\": \"<snap-02d4db3813ff9b98e>\"}}" \
   --ena-support --boot-mode uefi \
   --region eu-central-1 \
   --uefi-data $(cat aws_blob.bin)
   --output json

   {
       "ImageId": "example-ami-id"
   }

4. Reboot the instance from the AWS Console.