UEFI boot entries

This is how AnotherOS makes an installed disk the firmware's default boot — the Boot#### and BootOrder variables every UEFI machine uses, and Apple's startup-disk variables on a Mac.

What the kernel provides

UEFI runtime services, variable services only.

The bootloader hands the kernel the EFI system table and the firmware's memory map after it has exited boot services. The kernel maps every runtime region into a private page table and calls the firmware's variable functions in physical mode — it never asks the firmware to switch to virtual addressing.

Each call is serialised, saves the floating-point state and hands the firmware a clean one, and runs with preemption disabled.

A CPU exception inside firmware code is caught. The call returns an error, runtime services are disabled for the rest of the boot, and the log names the firmware region the fault touched. Firmware is other people's code running in your address space; treating a fault in it as fatal would make one vendor's bug an unbootable machine.

Boot-services memory is kept

The UEFI specification says firmware does not use boot-services memory after exiting boot services. Some firmware does anyway — on one Mac the first variable write faulted inside the firmware reading a page the kernel had not mapped, while every read had worked perfectly.

So, following Linux, the kernel reserves every boot-services region before its first allocation and maps it alongside the runtime regions on every machine. They are released only when it is certain no runtime call will ever be made.

When the firmware refuses to write

Some firmware refuses every new non-volatile variable in physical mode — reads work, writes do not — and will only accept them after the virtual-address switch that neither Linux nor macOS skips on those machines.

A command-line option makes that call the way Linux does. It is one-shot and cannot be undone within a boot, which is exactly why it is an option and not the default.

/sys/firmware/efi

This exists only on a UEFI boot, which is how a tool tells UEFI from BIOS.

Path	Contents
fw_platform_size	64
fw_vendor_name	The firmware vendor string
fw_revision	The UEFI revision
runtime_state	live, faulted (a firmware fault disabled services this boot) or unavailable. Read live, so it tells the truth after a fault.
efivars/	One file per variable, in Linux's efivarfs format

Each variable file is a 4-byte little-endian attributes word followed by the data. Reading it asks the firmware. Writing attributes and data in one write sets it; creating the file and then writing it creates the variable; unlinking deletes it — always by asking the firmware, so removing a name it does not have is answered honestly rather than silently succeeding.

Variable names beyond the filesystem's name limit are not published.

The write policy

The kernel enforces this. It is not advisory.

Allowed	Variables
Write	Boot####, BootOrder, BootNext, and the Apple startup-disk variables
Delete	Boot####, BootNext
Anything else	Refused with EPERM, and logged

Every accepted write must also carry exactly the non-volatile, boot-services and runtime attributes, stay within a size limit, and pass the same validators Linux applies to that variable.

This is deliberate and worth understanding before you complain about it. Firmware variable storage is finite, and on a number of real machines filling it bricks the board. A general-purpose "write any EFI variable" interface is a way to destroy hardware from userspace, so this kernel exposes boot selection and nothing else.

aefiboot

aefiboot is the tool that reads and writes boot entries — the equivalent of efibootmgr. It lists what the firmware has, creates an entry for an installed system, and sets the boot order, all through the interface above.

On a Mac it also handles the startup-disk variables, which is what makes an installed AnotherOS appear alongside macOS in the boot picker rather than needing a key held at power-on every time.

What is proven, and what is not

Reading variables, enumerating them and publishing them works on every UEFI machine tried.

Writing works where the firmware accepts physical-mode writes. Where it does not, the virtual-address-switch path exists and is proven under firmware emulation, but has not yet been exercised on the Mac that needs it — so it is available, off by default, and described here as exactly that rather than as a solved problem.

Boot-once, for kernel packages

A kernel installed as a package can be booted once without becoming the default, so a kernel that fails to come up leaves the machine still able to boot the previous one by power-cycling it. That is the difference between trying a kernel and betting the machine on it.