Hi, was the detail in other thread?
@wsmather I have been looking more into this, and the issue in part is due to the fact that there have been noted vulnerabilities in .efi shims
Their is a Linux alternative, LibreBoot which uses CoreBoot as its base, but appears to be limited to specific notebooks. As a mere mortal I would not know where to begin to adopt it and would not want to brick my system.
The issue is around bootkits. I used Brave A.I. with past month criteria for period of time:
" The primary attack vector allowing bootkits into Linux EFI shims is the LogoFAIL vulnerability (a UEFI firmware flaw), which allows attackers to embed malicious shellcode in logo images to exploit out-of-bounds writes and modify the Machine Owner Key (MOK) list at runtime. This unauthorized modification effectively authorizes self-signed or malicious bootloaders (such as Bootkitty or BlackLotus ) to bypass Secure Boot integrity checks without user interaction. Additionally, vulnerabilities in GRUB2 (such as those allowing arbitrary code execution in grub.cfg ) and shim (CVE-2024-7344, which bypassed signature verification via a custom PE loader) provide further entry points for remote or local attackers to inject malicious code into the boot chain.
To protect against these bootkits, you should disable or avoid using HTTP Boot and PXE boot if not strictly necessary, as these features can be exploited to chainload malicious shims from remote servers. It is critical to use your own custom Secure Boot keys exclusively rather than relying on Microsoftâs third-party certificates, which have been compromised in past exploits; this prevents attackers from abusing trusted Microsoft-signed binaries. Furthermore, avoid using fwupd for automatic firmware updates and instead perform manual firmware image updates to prevent attackers from placing malicious logo images or binaries on the EFI System Partition (ESP) via firmware update mechanisms. Finally, ensure your EFI partition is read-only or unmounted in everyday situations to limit the ability of local root users or malware to overwrite critical bootloader binaries like grubx64.efi .
AI-generated answer. Please verify critical facts."
And:
How do custom Secure Boot keys work?
Custom Secure Boot keys work by replacing or supplementing the default manufacturer keys (typically Microsoftâs) with a user-generated key hierarchy , allowing you to establish your own Root of Trust rather than relying on third-party vendors. This process involves generating four specific key types that form a strict cryptographic chain: the Platform Key (PK) , which is the ultimate root owned by you; the Key Exchange Key (KEK) , which authorizes updates to the signature databases; the Signature Database (db) , containing public keys of allowed bootloaders; and the Forbidden Signature Database (dbx) , listing revoked keys.
When you implement custom keys, you typically enter Setup Mode in your UEFI firmware to clear existing keys, then generate and enroll your own PK, KEK, and db keys. Once enrolled, the firmware will only execute bootloaders, kernels, and drivers that are cryptographically signed by your private keys. This prevents attackers from exploiting vulnerabilities in Microsoft-signed binaries (like the shim or GRUB2) because those third-party signatures are no longer trusted by your system unless you explicitly choose to append them. Tools like sbctl on Arch Linux or pesign on RHEL automate the generation of these X.509 certificates and the signing of binaries like vmlinuz and grubx64.efi .
It is crucial to distinguish custom Secure Boot keys from Machine Owner Keys (MOK) . MOKs are a shim-specific mechanism that allows users to enroll keys for kernel modules (like NVIDIA drivers) without modifying the firmwareâs actual db; they rely on the existing Microsoft-signed shim to validate the MOK enrollment request. In contrast, custom Secure Boot keys replace the firmwareâs root of trust entirely, removing the dependency on Microsoftâs infrastructure and providing a higher security posture against supply-chain attacks targeting the default key hierarchy."