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, the motherboard
and the on-board firmware could be considered the
platform. Or, put slightly differently, 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, some driver
located in the flash memory of some PCI Express card or on disk, or be
it an update of the firmware itself.
Essentially, if you want 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, as long as they are signed with the private part of the PK.
Microsoft’s Key Exchange Key (KEK) is installed by default.
NOTE: GUID Partitioning Table (GPT) Required
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 essentially requires having a boot loader with a digital signature that the firmware recognizes as a trusted key. In order to be useful to SUSE Linux Enterprise customers, 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 (i.e., have it signed with their KEK). By now, SUSE got the loader signed by UEFI Signing Service (that's Microsoft in this case).
Figure 12-1 UEFI: Secure Boot Process
At the implementation layer, SUSE uses the shim loader—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 eLILO or GRUB2 and verify it; this boot loader in turn will load kernels signed by a SUSE key only. SUSE provides this functionality with SLE11 SP3 on fresh installations with UEFI Secure Boot enabled.
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, but 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.
The various 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 matter that is both secure and open source friendly, and thus compatible
SUSE starts with shim—a small and simple EFI boot loader—which was originally developed by Fedora. It is signed by a certificate signed by the SUSE KEK and a Microsoft-issued certificate, based on which KEKs are available in the UEFI key database on the system.
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.
If the user (
machine owner) wants to replace any
components of the boot process, Machine Owner Keys (MOKs) are to be
used. The mokutils tool will help with
signing components and managing MOKs.
The enrollment process begins with rebooting the machine and interrupting the
boot process (e.g., pressing a key) when shim
loads. shim will then go into enrollment mode,
allowing the user to replace the default SUSE key with keys from a file on the
boot partition. If the user chooses to do so, shim
will then calculate a hash of that file and put the result in a
Services Only variable. This allows shim to
detect any change of the file made outside of Boot Services and thus avoid
tampering with the list of user-approved MOKs.
All of this happens during boot time—only verified code is executing
now. Therefore, only a user present at the console can use the machine owner's set of
keys. It cannot be malware or a hacker with remote access to the OS
because hackers or malware can only change the file, but not the hash
stored in the
Boot Services Only variable.
The boot loader, once loaded and verified by shim, will call back to shim when it wants to verify the kernel—to avoid duplication of the verification code. Shim will use the same list of MOKs for this and tell the boot loader whether it can load the kernel.
This way, you can install your own kernel or boot loader. It is only necessary to install a new set of keys and authorize them by being physically present during the first reboot. Because MOKs are a list and not just a single MOK, you can make shim trust keys from several different vendors, allowing dual- and multi-boot from the boot loader.
The following is based on http://en.opensuse.org/openSUSE:UEFI#Booting_a_custom_kernel.
Secure Boot does not prevent you from using a self-compiled kernel. You just 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 http://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 -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.
Alternatively, this is the procedure if you want to launch MOK manually:
In the GRUB menu press the 'c' key.
chainloader $efibootdir/MokManager.efi boot
Navigate to the cert.der file and press Enter.
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.
There is no support for adding non-inbox drivers (that is, drivers that do not come with SLE) after having booted into the installation with Secure Boot enabled. The signing key used for SolidDriver/PLDP is not trusted by default.
However, it ispossible to use third party drivers during installation with Secure Boot enabled in two different ways:
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 to an empty CD/DVD media.
Start the installation by booting from the new CD/DVD media, having the standard SUSE Linux Enterprise 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 disk of the SUSE Linux Enterprise 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.
When booting in Secure Boot mode, the following restrictions apply:
Hybridified ISO images are not recognized as bootable on UEFI systems. Thus, UEFI booting from USB devices is not supported with SP3.
To ensure that Secure Boot cannot be easily circumvented, some kernel features are disabled when running under Secure Boot.
Bootloader, kernel, and kernel modules must be signed.
kexec and kdump are disabled.
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.
acpi_rsdp parameter does not have any effect on the kernel.