Living with Secure Boot
I bought a new laptop Aspire A515-45, AMD 6 core Ryzen 5 5500U with Radeon Graphics, 16Gb DDR4 ram and 512Gb nvme SSD.
It comes preloaded with Windows 11 and therefore secure boot is enabled by default. Installed AlmaLinux 8.6 with minimal issues, just remember to mount /boot/efi to the first partition of the SSD drive. The Almalinux shim is already correctly signed so there were no issues with booting up the system.
Drivers for the wifi, Intel Wi-Fi 6 AX200 and ethernet, Realtek RTL8111/8168/8411 PCI Express Gigabit Ethernet were loaded correctly.
However the drivers for the AMD integrated Radeon graphics were quite basic. AMD provides better graphic drivers ( AMDGPU ) obtained from http://repo.radeon.com/amdgpu-install/. RPM packages for RHEL 8.6 are available. Installation also involves the creation of the amdgpu kernel module. As the newly created amdgpu module is unsigned, it was not loaded during bootup. Similarly manual loading will not work due to the secure boot environment.
A mok certificate had been been created which need to be imported before the amdgpu kernel module is permitted to load.
mokutil --import /root/mok.der
Mokutil will require you to provide a temporary password for importing the certificate. Reboot the system and the MOK manager will start automatically.
Information on how the Mok enrollment screens can be found here.
Use to temporary password to complete the importing of the certificate. The amdgpu driver will now loads correctly.
New Issues
I noticed a new problem where upon resumption from standby, the display remains blank. The system is running but there is no display, only a reboot will bring it back.
Apparently this is an issue on AMD CPU concerning standby, only a newer kernel has the fix for this issue. The current kernel is kernel-4.18.0-372.9.1.el8.x86_64.
Recommendation was to use a version 5 kernel. Instead of compiling a kernel, I took a kernel rpm from ELRepo Project.
It had current stable kernel version release 5.18.1-1.el8.elrepo.x86_64.
I installed the elrepo kernel and upon reboot, the new kernel fails to load. This was expected as the secure boot does not have the public certificate for elrepo. I turned off secure boot setting in the BIOS and the 5.18 kernel booted up just fine. The standby issue is resolved.
Apparently the elrepo kernel and modules are unsigned, therefore this is no public certificate to import. In order to re-enable secure boot and permit the loading of the elrepo kernel, I would need to create my own set of keys/certs and sign the elrepo kernel and kernel modules.
I used the information at this link to get the elrepo kernel/modules signed.
How to sign things for secure boot
I needed to build these packages for the sbsign utility
gnu-efi-3.0.11-6.fc34.src.rpm
sbsigntools-0.9.4-4.fc34.src.rpm
sbsign is used to sign the kernel binary.
I found kmodsign in my system as provided by the snap package. It was used to sign the kernel modules.
Alternately you could use sign-file to sign the modules. It comes from the kernel-devel rpm. See link below for information on this alternate kernel module signing process.
signing-kernel-modules-for-secure-boot
For the kernel module signing process, you will need to uncompress the kernel modules to .ko, sign them and compress them back to ko.xz.
After importing the self created certificate with the Mok utility and re-enabling secure boot. The elrepo kernel/modules were able to load successfully.
What's up with Secure Boot
Secure boot was implemented in the release of Windows 8 in 2012. Microsoft introduced digitally signed kernel files for Windows PE, Windows RT, Windows 8, and Windows Server 2012.
With the release of Windows 11 in 2021, Secure Boot became a mandatory requirement in PC systems preloaded with Windows 11.
Secure Boot is one feature of the Unified Extensible Firmware Interface (UEFI) 2.3.1 specification (Errata C). The feature defines an entirely new interface between operating system and firmware/BIOS.
When enabled and fully configured, Secure Boot helps a computer resist attacks and infection from malware. Secure Boot detects tampering with boot loaders, key operating system files, and unauthorized option ROMs by validating their digital signatures.
After Secure Boot is enabled and configured, only software or firmware signed with approved keys are allowed to execute. Conversely, software signed with blacklisted keys are disallowed from executing.
Secure Boot is split into several pieces and stages.
db, the “signature database.” Entries here (typically certificates) determine what EFI executables are allowed to run on the device. So this is an “allow” list.
dbx, the “forbidden signatures database.” Entries here are typically SHA256 hashes of specific UEFI binaries, i.e. those things that were signed by a certificate in the “db” list but later found to be bad (e.g. having a security vulnerability that compromises the firmware). So this is a “block” list.
kek, the “key exchange key.” This specifies who is able to update the signature database (the “db” and “dbx” keys). Interestingly, any UEFI binaries signed by the “kek” key can also boot on the device. Microsoft's certificate will be stored here.
pk, the “platform key.” The “pk” variable contains a single certificate that controls access to the “kek” and “db” variables. If this value is cleared, it effectively turns off Secure Boot (putting the device in setup mode). For example, if the manufacturer of the hardware is Dell, then their certificate will be stored here.
For Linux systems, a special boot loader Shim created by Matthew Garrett is used to integrate with the Secure Boot setup. It manages its own certificates. Ubuntu, Red Hat, SUSE, and Debian generate their own versions of Shim that include certificates issued by their companies.
Verisign/Symantec for a fee will digitally signs the Shim bootloader on behalf of Microsoft that the UEFI firmware will permit the loading of the Shim. Once Shim is loaded, it operates independently of the Microsoft verification chain. Shim has built-in certificate management that lets the owner of the computer store certificates called machine owner keys (MOKs).
Shim lets large distributors such as Ubuntu, SUSE, and Red Hat win back control of hardware. Using the Distribution certificate stored in Shim, The Distribution sign the GRUB 2 bootloader. The firmware boots Shim, Shim boots GRUB 2, and GRUB 2 boots the operating system.
A Machine Owner Key (MOK) is a type of user generated key that is used to “sign," or authenticate as trustworthy, an Extensible Firmware Interface (EFI) binary. MOK gives you ownership of the boot process by allowing you to run locally-compiled kernels, kernel modules or boot loaders not delivered with the Linux distribution. This means that to use custom kernel or kernel modules, A public MOK needs to be enrolled and the private MOK is used to sign the custom kernel and kernel modules.