34Apple Platform Security
When LLB (which stands for Low Level Bootloader) is launched, it then verifies the
signatures and loads system-paired firmware for intra-SoC cores such as the storage,
display, system management, and Thunderbolt controllers. LLB is also responsible for
loading the LocalPolicy, which is a file signed by the Secure Enclave Processor.
The LocalPolicy file describes the configuration that the user has chosen for the system
boot and runtime security policies. The LocalPolicy has the same data structure format as
all other boot objects, but it’s signed locally by a private key that’s available only within
a particular computer’s Secure Enclave instead of being signed by a central Apple server
(like software updates).
To help prevent replay of any previous LocalPolicy, LLB must look up an anti-replay
value from the Secure Enclave–attached Secure Storage Component. To do this, it uses
the Secure Enclave Boot ROM and makes sure the anti-replay value in the LocalPolicy
matches the anti-replay value in the Secure Storage Component. This helps prevent an old
LocalPolicy—which could have been configured for lower security—from being reapplied to
the system after security has been upgraded. The result is that secure boot on a Mac with
Apple silicon helps protect not only against rollback of operating system versions but also
against security policy downgrades.
The LocalPolicy file captures whether the operating system is configured for Full, Reduced,
or Permissive security.
• Full Security: The system behaves like iOS and iPadOS, and allows only booting
software which was known to be the latest that was available at install time.
• Reduced Security: LLB is directed to trust “global” signatures, which are bundled with
the operating system. This allows the system to run older versions of macOS. Because
older versions of macOS inevitably have unpatched vulnerabilities, this security mode
is described as Reduced. This is also the policy level required to support booting kernel
extensions (kexts).
• Permissive Security: The system behaves like Reduced Security in that it uses global
signature verification for iBoot and beyond, but it also tells iBoot that it should accept
some boot objects being signed by the Secure Enclave with the same key used to sign
the LocalPolicy. This policy level supports users that are building, signing, and booting
their own custom XNU kernels.
If the LocalPolicy indicates to LLB that the selected operating system is running in Full
Security, LLB evaluates the personalized signature for iBoot. If it’s running in Reduced
Security or Permissive Security, it evaluates the global signature. Any signature verification
errors cause the system to boot to recoveryOS to provide repair options.
After LLB hands off to iBoot, it loads macOS-paired firmware such as that for the
Secure Neural Engine, the Always On Processor, and other firmware. iBoot also looks at
information about the LocalPolicy handed to it from LLB. If the LocalPolicy indicates that
there should be an Auxiliary Kernel Collection (AuxKC), iBoot looks for it on the file system,
verifies that it was signed by the Secure Enclave with the same key as the LocalPolicy,
and verifies that its hash matches a hash stored in the LocalPolicy. If the AuxKC is verified,
iBoot places it into memory with the Boot Kernel Collection before locking the full memory
region covering the Boot Kernel Collection and AuxKC with the System Coprocessor
Integrity Protection (SCIP). If the policy indicates that an AuxKC should be present but it
isn’t found, the system continues to boot into macOS without it. iBoot is also responsible
for verifying the root hash for the signed system volume (SSV), to check that the file
system the kernel will mount is fully integrity verified.