Boot loop or recovery picker, never m1n1

macOS 27 beta breaks Asahi Linux on Apple Silicon. The failure lands at the handoff between iBoot and the Asahi boot object. Dual-boot machines drop into a boot loop or fall back to the macOS recovery picker instead of chaining into m1n1. No CVE is assigned. That absence is the first fact worth stating, because the headline calls this a bootloader vulnerability and it is not one.

The premise carries two errors, and the corrections matter more than the regression.

Apple Silicon does not use UEFI. There is no vendor UEFI firmware on an M-series Mac. The boot chain is SecureROM, an immutable mask ROM burned into the SoC, then the Low Level Bootloader, then iBoot. iBoot validates and loads a signed kernelcache. The trust root is Apple’s, anchored in the Secure Enclave, with no EDK2, no DXE phase, no option ROMs, and no UEFI variable store. The architecture Apple shipped in 2020 exists partly to delete the pre-boot attack surface that the PC UEFI stack accumulated over two decades.

Asahi reintroduces a slice of that surface by necessity. iBoot on an Apple Silicon Mac will only boot a Mach-O it recognises as a kernelcache. Asahi packages m1n1, a device tree, and U-Boot into an image staged so iBoot loads it as if it were that kernelcache. m1n1 brings up the hardware Apple never documented. U-Boot then synthesises an EFI environment in software, because the Linux kernel, GRUB, and systemd-boot expect EFI boot services and runtime services to exist. The UEFI layer in an Asahi boot is not Apple’s and not firmware. It is U-Boot emulating enough of the spec for a generic distro to boot. That software EFI shim is the only thing in the chain that resembles UEFI at all.

Booting third-party code at all requires lowering the machine’s security posture. Every OS install on Apple Silicon carries a LocalPolicy, a per-install policy object signed by the Secure Enclave using the owner’s credentials at the time it was set. Three levels exist. Full Security enforces the complete Apple chain of trust. Reduced Security permits older or third-party signed kernels. Permissive Security allows arbitrary unsigned kernels and relaxes kernel integrity enforcement for that install. Asahi requires Permissive Security, set once from One True Recovery during install. That is a deliberate, owner-authorised downgrade, and it is scoped to the Linux volume, not the machine.

The regression itself is a compatibility break, not a memory-corruption primitive. A macOS beta that changes how iBoot enumerates or stages boot objects, or changes the on-disk format the installer writes, or alters bputil and kmutil policy handling, breaks the assumption Asahi’s stub relies on. The stub is staged in a shape a specific iBoot expected. Change iBoot, and the shape no longer parses. The kernel that broke is Apple’s boot picker logic, not an authentication check. Nobody bypasses a login prompt here. A dual-boot configuration stops resolving. Root on the Linux side was already authorised by the owner through the policy downgrade months earlier.

That is where the headline’s third claim collapses. Booting custom code before security software loads is not the exploit in this story. It is the design, opted into by the owner, on a machine the owner physically controls. Pre-OS code execution is only an attack when it crosses a trust boundary without authorisation. Asahi crosses no boundary. It holds a signed policy that grants exactly this.

The genuine security lesson sits one layer up, and real bootkits live there. Code that runs before the kernel runs before any runtime telemetry exists. On Windows, Early Launch Anti-Malware loads as a boot-start driver, but a bootkit that executes before ELAM sees nothing of it. Sysmon has not initialised. ETW providers are not emitting. On macOS, Endpoint Security framework clients are userspace processes that attach after the kernel is up. Nothing in the EDR stack observes the LLB-to-iBoot-to-kernelcache handoff. The pre-boot stage is a telemetry void by construction, on every platform.

The MITRE mapping is T1542, Pre-OS Boot, with T1542.003 Bootkit and T1542.001 System Firmware as the sub-techniques. Lowering a signed boot policy to load unsigned code maps to T1553.006, Code Signing Policy Modification. These are the techniques that matter, and the CVEs that carry them are UEFI CVEs, which is the irony the headline missed.

BlackLotus weaponised CVE-2022-21894, the baton drop flaw, a Secure Boot bypass with a CVSS base of 4.4 that became the first in-the-wild UEFI bootkit to defeat Secure Boot on fully patched Windows 11. BootHole, CVE-2020-10713, is a buffer overflow in GRUB2’s parser of grub.cfg, CVSS 8.2, that let attackers run code in the UEFI boot phase and break the Secure Boot chain even on signed GRUB. LogoFAIL, disclosed in 2023, is a set of image-parser flaws in the DXE drivers that render boot logos, exploitable by planting a malformed image so a bootkit persists below the OS across reinstalls. PKfail, 2024, exposed production firmware from many vendors shipping AMI test Platform Keys stamped DO NOT TRUST, collapsing the root of the Secure Boot trust chain across hundreds of models. Every one of these is a UEFI trust-model failure. Apple Silicon is vulnerable to none of them, because it has no UEFI to attack.

The persistence tier separates a boot problem from a boot implant. A bootkit that writes only to the EFI System Partition survives a reboot but not a disk wipe or a clean OS reinstall. A bootkit that writes to SPI flash, the physical chip holding the platform firmware, survives reimaging, drive replacement, and OS reinstall, because the malicious code lives below the disk entirely. That is the class defenders fear, and it is not theoretical. LoJax, reported by ESET in 2018 and attributed to Sednit, also tracked as APT28, was the first in-the-wild UEFI rootkit, rewriting SPI flash to reinstall its payload on every boot. MoonBounce, attributed by Kaspersky to APT41, hid in the CORE_DXE region of SPI flash and left no artifact on disk at all. CosmicStrand, another SPI-resident implant, patched a specific vendor’s firmware to hook the boot chain. Each defeated OS reinstallation by design, and each ran entirely beneath the layer any EDR agent can observe.

What an attacker actually needs at this layer is the second correction to the risk framing. Reaching SPI flash requires either a firmware write vulnerability, physical access to the chip, or existing administrative code execution that can flash the part. None of that is remote, unauthenticated, or granted for free by a boot chain. The pre-boot stage is where the payload hides after compromise, not the door through which compromise arrives. A bootkit is a persistence and evasion technique, T1542.003, reached after initial access and privilege escalation, not an initial access vector. The headline inverts that order, promising root before any security software reacts. The bootkit gets there only after an operator already held admin on the box.

Detection at this layer does not come from EDR. It comes from measured boot. On PC hardware, each stage hashes the next into TPM Platform Configuration Registers, and remote attestation compares those PCR values against a known-good baseline. A bootkit that alters an earlier stage changes a downstream measurement, and the attestation check fails even though no runtime agent saw the code run. Apple Silicon has no TPM. Integrity comes from the Signed System Volume, a sealed APFS snapshot whose contents hash up to a signature iBoot verifies before boot, plus CTRR locking the kernel text region read-only in hardware after load. Under Permissive Security, an Asahi install steps outside SSV enforcement for its own volume by design. The macOS volume’s seal is untouched.

The telemetry reality for defenders is blunt. A SIEM correlating Sysmon and ESF events has zero visibility into anything below the kernel. The first observable event fires after kernel initialisation. A boot policy downgrade on Apple Silicon is visible through bputil and the LocalPolicy state, and a fleet that monitors boot security level would see a machine drop from Full to Permissive. That is the detection worth building for the risk that is real: not the Asahi regression, but an unauthorised policy downgrade on a managed device, which is the only path by which pre-boot execution on this hardware becomes an intrusion rather than a feature. Escalate any such change to the team that owns the fleet’s device posture, because a Permissive downgrade the owner did not perform is the signal that matters.

The patch boundary is the honest close. This is a beta. Apple will realign iBoot’s boot-object handling or Asahi will re-stage its stub to match, and dual-boot resolves again. The residual exposure is unchanged either way, because it was never the regression. It is architectural, and it predates this beta. Any code that runs before the kernel runs before detection, and no runtime EDR closes that gap. On Apple Silicon the pre-boot chain is Apple-signed and hardware-anchored, which is a stronger position than the UEFI stack the headline blamed. The weakness the story points at is real. It just lives on the machines that still boot the way the headline assumed this one does.