| created on | November 23, 2025 |
The kernel configuration parameter enables EFI Runtime Services in the kernel.
If the system is booted in UEFI mode, then:
There are two kinds of UEFI vars exposed to the OS:
The Linux kernel exposes UEFI variables to userspace via the efivarfs (EFI Variable File System), mounted at . A typical entry in would be:
To mount the efivarfs:
Blasting over a directory structure with efivars mounted in read/write mode with shouldn’t brick your machine, because there are fall-backs in every sane UEFI implementation for dealing with such cases. But …
Mounting efivarfs with write access can potentially cause significant harm to your machine. It increases the attack surface of your machine for exploits like LogoFail which is not vendor-specific. In some cases of poor UEFI implementations, standard fall-backs might not work or even standard operations can brick your machine.
There are several cases of users reporting that a over a directory structure with efivarfs mounted did hard-brick their machines.
A better approach is to mount the efivarfs read-only during boot:
To manipulate the EFI vars, unmount the efivarfs and remount it in read/write mode. After manipulating the EFI vars, unmount the efivarfs again and remount it in read-only mode. Notably, distros with systemd do not take this approach.
Access to EFI vars can be completely disabled with the kernel parameter.
EFI applications must be compiled for the specific firmware/processor bitness/architecture. A x64 (64-bit) UEFI firmware does not include support for launching 32-bit EFI applications.
The vast majority of machines now use x86 UEFI and apart from ancient machines it is unlikely to encounter an IA32 (32-bit) UEFI. However, the UEFI bitness can be checked by looking at the EFI var which is in the efivars:
is 64 for a x64 UEFI, or 32 for a IA32 UEFI.
binarly, Finding LogoFAIL: The Dangers of Image Parsing During System Boot
github, systemd/systemd, Mount efivarfs read-only #2402