Low-Level Bootloader (LLB) Security on macOS

My last article was about the Boot ROM stage of Silicon Macs, its security design, and related exploits. This article covers the same topics for the Low-Level Bootloader (LLB) stage. If I missed a notable exploit, please let me know. Let’s get started!

After the Boot ROM authenticates and launches the LLB, it runs. The LLB is a small bootloader stored in the Mac’s internal storage, specifically, in a protected flash or a reserved partition of the SSD. It serves as the second link in the chain of trust. The Apple Silicon LLB’s duties include:

initializing more system hardware,
loading firmware for various coprocessors,
loading the system’s LocalPolicy, and
applying the Mac’s boot security policy

TLDR: LLB verifies the integrity of critical firmware components and reads the user-configured security mode to determine how strictly to enforce Secure Boot for the OS.

Security

LLB continues the chain of trust by verifying all firmware components it loads (e.g., storage controller firmware, Thunderbolt controller firmware, display firmware, etc.) using signatures. This ensures that even the auxiliary processors in the SoC run only Apple-trusted code, preventing a malicious firmware from tampering with storage or DMA to memory.

Local Policy

Next, LLB loads LocalPolicy, a signed policy file that lives on the internal storage (in the iSCPreboot container) and is unique to the Mac.

The iSCPreboot container is a hidden, internal APFS storage area that holds machine-specific boot security metadata, including each boot volume’s signed LocalPolicy.

Secure Enclave

The LocalPolicy file is signed by the Mac’s Secure Enclave (SEP) using a device-specific private key in the SEP. This file encodes the boot security mode the user has selected (e.g., Full Security, Reduced, or Permissive), and other boot settings. Because it’s signed by the Secure Enclave on that machine, it cannot be forged or modified by an attacker. Only the SEP, which requires user authentication and physical presence in Recovery OS to change security settings, can sign a new policy.

The Secure Enclave is a hardware feature (source).

LLB verifies the LocalPolicy’s signature and also checks an anti-replay counter in the SEP’s secure storage to ensure the policy is the latest one and not a rollback to a weaker setting. This anti-replay mechanism prevents an attacker from tricking the system into using an older LocalPolicy that might have “Reduced Security” when the user has since upgraded to Full Security.

In effect, once a Mac is set to a higher security level, LLB will refuse to accept any policy file that lowers it, unless it’s properly signed fresh via the SEP with user consent. This protects against downgrade attacks. For instance, an attacker with disk access can’t replace the policy file with one that allows booting unapproved OS versions or kernel extensions, because the anti-replay value wouldn’t match.

LLB validation

Based on the LocalPolicy, LLB determines how to validate the next stage (iBoot) and macOS itself.

In Full Security mode, LLB and subsequent stages will only boot the most up-to-date Apple-signed OS authorized at install time. I think this is similar to iOS devices.

In Reduced Security mode, the Mac will allow booting older or non-latest macOS releases (still Apple-signed) and will allow loading user-approved kernel extensions, which Full Security would forbid. Reduced Security trusts “global” (Apple’s general) signatures for iBoot and kernel, rather than device-personalized ones.

Permissive Security is an even lower setting intended for developers/experimenters. It’s like Reduced Security. But it also tells iBoot to accept a custom-built kernel signed with the user’s own Secure Enclave key, allowing one to boot a custom OS like Linux if it’s properly signed by the SEP. Even in Permissive mode, iBoot and other components are still verified, but users can sign their own kernel/Auxiliary Kernel Collection with the SEP’s key for boot.

I think I’ll do a future blog post on custom built kernels – stay tuned for that!

These tiered policies let users disable or relax certain security checks, but only with explicit steps (like booting into Recovery and authenticating), and with the system’s cryptographic approval. In all cases, LLB uses cryptographic signatures to ensure the integrity of what it loads next, according to the chosen policy.

LLB stage attacks

I could not find any big exploits specifically in the LLB stage on Silicon Macs. I think this is partly due to the short window LLB runs and its limited, hardened functionality.

However, I could consider theoretical vectors.

If an attacker somehow gained write access to the iBoot flash or iSCPreboot volume, they might try to replace LLB or the LocalPolicy file. The chain of trust prevents this. A modified LLB would not have a valid Apple signature for the Boot ROM to accept, and a tampered LocalPolicy would not have a valid SEP signature or anti-replay value, causing LLB to reject it. The anti-replay design also blocks rollbacks. An attacker with only storage access can’t revert the Mac to a less secure state by restoring old policy data.

One potential attack vector is if the Secure Enclave itself had a vulnerability. Since SEP signs the LocalPolicy, a compromise in SEP could allow an attacker to sign a malicious policy (e.g., one that sets Permissive Security without user permission).

There have been cases on iPhones where researchers found vulnerabilities in SEP firmware, but none are publicly known for the M1/M2 SEP. Even in such a scenario, an attacker would likely need kernel privileges and a chain of exploits to reach the SEP. Apple really protects the Secure Enclave, and its communication channel to the application processor, making this extremely difficult.

Another angle attackers have used historically is hardware tampering or glitching.

For example, attackers may use voltage glitching or signal manipulation to bypass security checks. I actually accidentally did something like this during an OS update, and it fried my M4.

There’s no evidence this has been done to bypass Mac LLB. However, Apple’s Boot ROM and LLB likely include countermeasures (clock monitors, etc.) to make hardware attacks hard. Apple has mentioned environmental monitoring on iDevices to deter hardware tampering.

Here, environmental monitoring means on-chip checks for abnormal physical conditions, such as clock glitches, voltage faults, temperature extremes, or other tamper signals, that could indicate a hardware fault-injection attempt and trigger defensive behavior during early boot.

In summary, direct attacks on LLB are theoretical.

The combination of cryptographic enforcement and anti-rollback in this stage has so far held up. The presence of Reduced/Permissive Security modes introduces an avenue for attackers with physical access… namely, social engineering or coercing a user to lower the security policy. For instance, tricking a user into believing they need to enable Reduced Security to install some software.

Once a Mac is in Reduced Security, it will boot older macOS versions or allow third-party kexts, which could be exploited by attackers using known vulnerabilities in older OS builds. However, this requires direct access to the machine and convincing the user to change settings in Recovery, which requires admin credentials or boot authorization.

Apple’s documentation calls Reduced Security out as dangerous because older OSes will inevitably have unpatched vulnerabilities. This is more of a risk to users who knowingly loosen their settings than a typical “attack.” However, it is a reminder that the highest security is achieved only when Full Security is maintained.

Bootloader evolution

Apple refined this stage as needed. For example, with each macOS update, the system might update the LocalPolicy or LLB if required. LLB can be updated via firmware updates since it resides in flash storage.

Apple’s Platform Security guide explains how each Mac’s SEP generates its LocalPolicy signing key during first boot and how those keys are managed. This personalization means an attacker can’t swap policy files between machines or craft one outside the device. Apple’s inclusion of Permissive mode reflects a balance between security and user flexibility (e.g., to allow projects like Asahi Linux to run on Apple Silicon by letting users authorize their own kernels).

Even Permissive mode is designed with care.

It still uses cryptographic signatures… just not Apple’s central signature. Additionally, permissive mode still verifies a hash of the custom kernel via the LocalPolicy as it boots. Thus, Apple enforces that no arbitrary code can run during early boot. Custom kernels must be deliberately and cryptographically authorized by the user’s SEP.

In response to potential threats at this stage, Apple has hardened the integrity of the policy mechanism. The anti-replay feature was new with Silicon to ensure attackers can’t downgrade security after the fact. Additionally, Silicon Macs rely on the internal SSD to store critical boot data, such as iBoot and LocalPolicy. If that internal storage is wiped or corrupted, the Mac cannot boot from external media until it is restored via DFU.

Learn more: Booting an M1 Mac from hardware to kexts: 1 Hardware – Dr. Howard Oakley

This design, while sometimes inconvenient, is a defense!! It ensures that all security-sensitive boot components remain on hardware tied to Apple’s chain of trust (internal, not easily swapped or externally modified).

Going forward, any flaw in LLB would presumably be patched in a macOS firmware update if possible. At worst, I think it would be addressed in the next hardware revision. To date, Apple’s layered verification (Boot ROM -> LLB -> iBoot) and the personalized LocalPolicy concept have kept the LLB stage protected.

iBoot

After LLB finishes its checks, it loads and transfers control to iBoot (often called the “boot firmware” on Macs). This will be the focus of my next post!

If you enjoyed this post on bootloader security, consider reading Boot ROM Security on Silicon Macs (M1/M2/M3).

Sources, thanks, and where to learn more about bootloaders