Applies to SUSE Linux Enterprise Desktop 15 SP5

17 UEFI (Unified Extensible Firmware Interface) #

UEFI (Unified Extensible Firmware Interface) is the interface between the firmware that comes with the system hardware, all the hardware components of the system, and the operating system.

UEFI is becoming more and more available on PC systems and thus is replacing the traditional PC-BIOS. UEFI, for example, properly supports 64-bit systems and offers secure booting (“Secure Boot”, firmware version 2.3.1c or better required), which is one of its most important features. Lastly, with UEFI a standard firmware will become available on all x86 platforms.

UEFI additionally offers the following advantages:

Booting from large disks (over 2 TiB) with a GUID Partition Table (GPT).
CPU-independent architecture and drivers.
Flexible pre-OS environment with network capabilities.
CSM (Compatibility Support Module) to support booting legacy operating systems via a PC-BIOS-like emulation.

For more information, see https://en.wikipedia.org/wiki/Unified_Extensible_Firmware_Interface. The following sections are not meant as a general UEFI overview; these are only hints about how certain features are implemented in SUSE Linux Enterprise Desktop.

17.1 Secure boot #

In the world of UEFI, securing the bootstrapping process means establishing a chain of trust. The “platform” is the root of this chain of trust; in the context of SUSE Linux Enterprise Desktop, the mainboard and the on-board firmware could be considered the “platform”. In other words, it is the hardware vendor, and the chain of trust flows from that hardware vendor to the component manufacturers, the OS vendors, etc.

The trust is expressed via public key cryptography. The hardware vendor puts a so-called Platform Key (PK) into the firmware, representing the root of trust. The trust relationship with operating system vendors and others is documented by signing their keys with the Platform Key.

Finally, security is established by requiring that no code will be executed by the firmware unless it has been signed by one of these “trusted” keys—be it an OS boot loader, a driver located in the flash memory of certain PCI Express card or on disk, or be it an update of the firmware itself.

To use Secure Boot, you need to have your OS loader signed with a key trusted by the firmware, and you need the OS loader to verify that the kernel it loads can be trusted.

Key Exchange Keys (KEK) can be added to the UEFI key database. This way, you can use other certificates, if they are signed with the private part of the PK.

17.1.1 Implementation on SUSE Linux Enterprise Desktop #

Microsoft’s Key Exchange Key (KEK) is installed by default.

Note: GUID partitioning table (GPT) required

The Secure Boot feature is enabled by default on UEFI/x86_64 installations. You can find the Enable Secure Boot Support option in the Boot Code Options tab of the Boot Loader Settings dialog. It supports booting when the secure boot is activated in the firmware, while making it possible to boot when it is deactivated.

Figure 17.1: Secure boot support #

The Secure Boot feature requires that a GUID Partitioning Table (GPT) replaces the old partitioning with a Master Boot Record (MBR). If YaST detects EFI mode during the installation, it will try to create a GPT partition. UEFI expects to find the EFI programs on a FAT-formatted EFI System Partition (ESP).

Supporting UEFI Secure Boot requires having a boot loader with a digital signature that the firmware recognizes as a trusted key. That key is trusted by the firmware a priori, without requiring any manual intervention.

There are two ways of getting there. One is to work with hardware vendors to have them endorse a SUSE key, which SUSE then signs the boot loader with. The other way is to go through Microsoft’s Windows Logo Certification program to have the boot loader certified and have Microsoft recognize the SUSE signing key (that is, have it signed with their KEK). By now, SUSE got the loader signed by UEFI Signing Service (that is Microsoft in this case).

Figure 17.2: UEFI: secure boot process #

At the implementation layer, SUSE uses the shim loader which is installed by default. It is a smart solution that avoids legal issues, and simplifies the certification and signing step considerably. The shim loader’s job is to load a boot loader such as GRUB 2 and verify it; this boot loader in turn will load kernels signed by a SUSE key only.

There are two types of trusted users:

First, those who hold the keys. The Platform Key (PK) allows almost everything. The Key Exchange Key (KEK) allows all a PK can except changing the PK.
Second, anyone with physical access to the machine. A user with physical access can reboot the machine, and configure UEFI.

UEFI offers two types of variables to fulfill the needs of those users:

The first is the so-called “Authenticated Variables”, which can be updated from both within the boot process (the so-called Boot Services Environment) and the running OS. This can be done only when the new value of the variable is signed with the same key that the old value of the variable was signed with. And they can only be appended to or changed to a value with a higher serial number.
The second is the so-called “Boot Services Only Variables”. These variables are accessible to any code that runs during the boot process. After the boot process ends and before the OS starts, the boot loader must call the ExitBootServices call. After that, these variables are no longer accessible, and the OS cannot touch them.

UEFI key lists are of the first type, as this allows online updating, adding and blacklisting of keys, drivers and firmware fingerprints. It is the second type of variable, the “Boot Services Only Variable”, that helps to implement Secure Boot in a secure and open source-friendly manner, and thus compatible with GPLv3.

SUSE starts with shim—a small and simple EFI boot loader signed by SUSE and Microsoft.

This allows shim to load and execute.

shim then goes on to verify that the boot loader it wants to load is trusted. In a default situation shim will use an independent SUSE certificate embedded in its body. In addition, shim will allow to “enroll” additional keys, overriding the default SUSE key. In the following, we call them “Machine Owner Keys” or MOKs for short.

Next the boot loader will verify and then boot the kernel, and the kernel will do the same on the modules.

17.1.2 MOK (Machine Owner Key) #

To replace specific kernels, drivers or other components that are part of the boot process, you need to use Machine Owner Keys (MOKs). The mokutil tool can help you to manage MOKs.

You can create a MOK enrollment request with mokutil. The request is stored in a UEFI runtime (RT) variable called MokNew. During the next boot, the shim boot loader detects MokNew and loads MokManager, which presents you with several options. You can use the Enroll key from disk and Enroll hash from disk options to add the key to the MokList. Use the Enroll MOK option to copy the key from the MokNew variable.

Enrolling a key from disk is normally done when the shim fails to load grub2 and falls back to loading MokManager. As MokNew does not exist yet, you have the option of locating the key on the UEFI partition.

17.1.3 Booting a custom kernel #

The following is based on https://en.opensuse.org/openSUSE:UEFI#Booting_a_custom_kernel.

Secure Boot does not prevent you from using a self-compiled kernel. You must sign it with your own certificate and make that certificate known to the firmware or MOK.

Create a custom X.509 key and certificate used for signing:
```
openssl req -new -x509 -newkey rsa:2048 -keyout key.asc \
  -out cert.pem -nodes -days 666 -subj "/CN=$USER/"
```
For more information about creating certificates, see https://en.opensuse.org/openSUSE:UEFI_Image_File_Sign_Tools#Create_Your_Own_Certificate.

Package the key and the certificate as a PKCS#12 structure:

> openssl pkcs12 -export -inkey key.asc -in cert.pem \
  -name kernel_cert -out cert.p12

Generate an NSS database for use with pesign:
```
> certutil -d . -N
```
Import the key and the certificate contained in PKCS#12 into the NSS database:
```
> pk12util -d . -i cert.p12
```

“Bless” the kernel with the new signature using pesign:

> pesign -n . -c kernel_cert -i arch/x86/boot/bzImage \
  -o vmlinuz.signed -s

List the signatures on the kernel image:
```
> pesign -n . -S -i vmlinuz.signed
```
At that point, you can install the kernel in /boot as usual. Because the kernel now has a custom signature the certificate used for signing needs to be imported into the UEFI firmware or MOK.
Convert the certificate to the DER format for import into the firmware or MOK:
```
> openssl x509 -in cert.pem -outform der -out cert.der
```
Copy the certificate to the ESP for easier access:
```
> sudo cp cert.der /boot/efi/
```
Use mokutil to launch the MOK list automatically.
- 1. Import the certificate to MOK:
```
> mokutil --root-pw --import cert.der
```
    The --root-pw option enables usage of the root user directly.
  2. Check the list of certificates that are prepared to be enrolled:
```
> mokutil --list-new
```
  3. Reboot the system; shim should launch MokManager. You need to enter the root password to confirm the import of the certificate to the MOK list.
  4. Check if the newly imported key was enrolled:
```
> mokutil --list-enrolled
```
- 1. Alternatively, this is the procedure to launch MOK manually:
    Reboot
  2. In the GRUB 2 menu press the 'c' key.
  3. Type:
```
chainloader $efibootdir/MokManager.efi
boot
```
  4. Select Enroll key from disk.
  5. Navigate to the cert.der file and press Enter.
  6. Follow the instructions to enroll the key. Normally this should be pressing '0' and then 'y' to confirm.
    Alternatively, the firmware menu may provide ways to add a new key to the Signature Database.

17.1.4 Using non-inbox drivers #

There is no support for adding non-inbox drivers (that is, drivers that do not come with SUSE Linux Enterprise Desktop) during installation with Secure Boot enabled. The signing key used for SolidDriver/PLDP is not trusted by default.

It is possible to install third party drivers during installation with Secure Boot enabled in two different ways. In both cases:

Add the needed keys to the firmware database via firmware/system management tools before the installation. This option depends on the specific hardware you are using. Consult your hardware vendor for more information.
Use a bootable driver ISO from https://drivers.suse.com/ or your hardware vendor to enroll the needed keys in the MOK list at first boot.

To use the bootable driver ISO to enroll the driver keys to the MOK list, follow these steps:

Burn the ISO image above to an empty CD/DVD medium.
Start the installation using the new CD/DVD medium, having the standard installation media at hand or a URL to a network installation server.
If doing a network installation, enter the URL of the network installation source on the boot command line using the install= option.
If doing installation from optical media, the installer will first boot from the driver kit and then ask to insert the first installation disk of the product.
An initrd containing updated drivers will be used for installation.

For more information, see https://drivers.suse.com/doc/Usage/Secure_Boot_Certificate.html.

17.1.5 Features and limitations #

When booting in Secure Boot mode, the following features apply:

Installation to UEFI default boot loader location, a mechanism to keep or restore the EFI boot entry.
Reboot via UEFI.
Xen hypervisor will boot with UEFI when there is no legacy BIOS to fall back to.
UEFI IPv6 PXE boot support.
UEFI video mode support, the kernel can retrieve video mode from UEFI to configure KMS mode with the same parameters.
UEFI booting from USB devices is supported.
Since SUSE Linux Enterprise Server 15 SP3, Kexec and Kdump are supported in Secure Boot mode.

When booting in Secure Boot mode, the following limitations apply:

To ensure that Secure Boot cannot be easily circumvented, certain kernel features are disabled when running under Secure Boot.
Boot loader, kernel, and kernel modules must be signed.
Hibernation (suspend on disk) is disabled.
Access to /dev/kmem and /dev/mem is not possible, not even as root user.
Access to the I/O port is not possible, not even as root user. All X11 graphical drivers must use a kernel driver.
PCI BAR access through sysfs is not possible.
custom_method in ACPI is not available.
debugfs for asus-wmi module is not available.
the acpi_rsdp parameter does not have any effect on the kernel.

17.2 More information #

https://www.uefi.org —UEFI home page where you can find the current UEFI specifications.
Blog posts by Olaf Kirch and Vojtěch Pavlík (the chapter above is heavily based on these posts):
https://en.opensuse.org/openSUSE:UEFI —UEFI with openSUSE.