| 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 runtime 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.