What does this mean? In most desktop and laptop UEFI Secure Boot capable off-the-shelf consumer and enterprise machines, UEFI Secure Boot is enabled. A default OEM-provided install of Windows comes default on these machines. That install has already created a GUID-based partition table, a FAT-formatted small "EFI" partition, and installed an EFI application (bootloader) into a default path within that filesystem. A DVD/USB install of Windows 8.1+ will do the same thing. That EFI bootloader is an extensible part of UEFI and provides the logic to retrieve, load, and begin executing an operating system (kernel).

If an attacker can run-time mount the small EFI partition and modify the bootloader, that attacker can execute code before the operating system kernel. In the most basic case this involves booting a separate kernel that lacks certain run-time security features. This level of access already means game over for your system's security, but allows attacks to continue to avoid detection or persist in more survivable ways. If you are interested in the specifics of the attack model and examples please read some of the firmware security "offensive" focused research.

To prevent this simple mount + replace bootloader attack UEFI may enforce signature checking of the bootloader. This is the first component and goal of UEFI Secure Boot. The systems mentioned before, and the Minnow, include a protected flash chip usually via an SPI bus and commonly called: SPI flash. These contain a set of flash regions and a firmware descriptor header. We will focus more on this flash chip later. For now, know that one region contains the UEFI platform code, which is one of the first things executed by the CPU on reset (power on). The SPI controller, in tandem with the UEFI platform code, and other protected run-time modes make sections of this region available as NVRAM. This means during UEFI platform execution and during operating system execution, these UEFI variables can be read and written.

There are two related Linux modules for reading and writing UEFI variables called: efi vars and efivars fs. The newer "efivars fs" is easier to write library integrations for-- and supports the latest UEFI-spec for NVRAM features. The out-of-the-box Ubuntu kernel, 3.19.0-26 supports the later, so much rejoicing was had! It actually supported both, so you're free to play around in the default-mounted sysfs structures to compare. There's one more important caveat for now: some of the most important UEFI variables are set within UEFI platform execution and are NOT backed by NVRAM storage. These are almost always read-only and provide important decision points for UEFI driver execution and the OS. To determine if a variable is backed by NVRAM storage check for the NV (EFI_VARIABLE_NON_VOLATILE) attribute.