Secure Boot for high performance computing software, as defined in the UEFI specification, provides an industry standard defense against potential malware attacks. Without Secure Boot, malware can attack systems during pre-boot by targeting the system-embedded firmware during the interval between BIOS initiation and operating system load.
Malware inserted at this point compromises the security of the operating system, no matter how secure. Secure Boot protects the system by preventing the insertion of malware during the pre-boot process. This technical white paper introduces Secure Boot technology and explains what it is, how it works and how to use it on UEFI-based HPE servers running Linux®.
What is Secure Boot?
Secure Boot, a high performance computing software solution, is a method to restrict which binaries can be executed to boot the system. With Secure Boot, the system BIOS will only allow the execution of boot loaders that carry the cryptographic signature of trusted entities.
In other words, anything run in the BIOS must be “signed” with a key that the system knows is trustworthy. With each reboot of the server, every executed component is verified. This prevents malware from hiding embedded code in the boot chain.
Secure Boot is:
• Intended to prevent boot-sector malware or kernel code injection.
• Hardware-based code signing.
• Extension of the UEFI BIOS architecture.
• Optional with the ability to enable or disable it through the BIOS.
For a more detailed description of what Secure Boot is and how it works, see the Resources section.
Chain of trust
SLES, RHEL 7.0, and greater distributions support a chain of trust which goes down to the kernel module level. Loadable kernel modules must be signed with a trusted key or they cannot be loaded into the kernel.
The following trusted keys are stored in UEFI NVRAM variables:
• Database (DB) – Signature database that contains well know keys. Only binaries that can be verified against the DB are executed by the BIOS.
• Forbidden Signature Database (DBX) – Keys that are blacklisted. Attempting to load an object with a key that matches an entry in the DBX will be denied.
• Machine Owner Key (MOK) – User added keys for kernel modules they want to install.
• Platform Key (PK) – The key installed by the hardware vendor.
• Key Exchange Key (KEK) – The key required to update the signature database.
The user must have physical access to the system console to add/modify keys or enable/disable Secure Boot through the UEFI configuration menu.
The default boot loader on most UEFI enabled servers running Linux is grub2 or elilo. With Secure Boot enabled, an additional “shim” boot loader is needed. When booting in Secure Boot mode, the shim loader is called first since it contains a trusted signature. The shim will then load grub2 or elilo which loads the OS kernel which is also signed.
HPE Server support for Secure Boot
HPE Gen9 servers and greater with UEFI enabled will support Secure Boot. To determine whether Secure Boot is supported on a specific platform and enabled or disabled by default, please check the system specifications.
Some Linux distributions extend the chain of trust to the kernel module. Consult the distribution’s documentation for what level of Secure Boot support is provided.
Limitations of Secure Boot
With Secure Boot enabled, some actions on a Linux system are either limited or restricted.
• Hybrid ISO images are not recognized as bootable on UEFI systems. Thus, UEFI booting from USB devices is not supported.
• Boot loader, kernel, and kernel modules must be signed.
• kexec and kdump are disabled.
• Hibernation (suspend on disk) is disabled.
• Read and Write access to /dev/kmem and /dev/mem is not possible, not even as root user.
• Access to I/O port is not possible, 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.
• acpi_rsdp parameter does not have any effect on the kernel.