Operating system integrity
Apple designs its operating systems with security at the core, with a hardware root of trust leveraged to enable secure boot and a secure software update process that enables quick and safe application of security updates. Apple operating systems also leverage purpose-built silicon-based hardware capabilities to help prevent exploitation as the operating system runs. These capabilities are not focused on whether or not to execute code (see App security for the mechanisms that help prevent malware and ensure only trusted code is executed) but instead focus on the capabilities afforded to code that is executed. In short, they help mitigate attack and exploit techniques whether those originate from a malicious app, from the web, or through any other channel. Protections listed here are available on devices with supported Apple-designed SoCs—this includes iOS, iPadOS, tvOS, watchOS, and now macOS on a Mac with Apple silicon.
See Note below.
Note: Page Protection Layer (PPL) requires that the platform execute only signed and trusted code; this is a security model that isn’t applicable on macOS.
Kernel Integrity Protection
After the operating system kernel completes initialization, Kernel Integrity Protection (KIP) is enabled to prevent modifications of kernel and driver code. The memory controller provides a protected physical memory region that iBoot uses to load the kernel and kernel extensions. After startup completes, the memory controller denies writes to the protected physical memory region. The Application Processor’s Memory Management Unit (MMU) is configured to prevent mapping privileged code from physical memory outside the protected memory region and to prevent writeable mappings of physical memory within the kernel memory region.
To prevent reconfiguration, the hardware used to enable KIP is locked after the boot process is complete.
Fast Permission Restrictions
Starting with the Apple A11 Bionic and S3 SoCs, a new hardware primitive was introduced. This primitive, Fast Permission Restrictions, includes a CPU register that quickly restricts permissions per thread. With Fast Permission Restrictions (also known as APRR registers), supported operating systems can remove execute permissions from memory without the overhead of a system call and a page table walk or flush. These registers provide one more level of mitigation for attacks from the web, particularly for code compiled at runtime (just-in-time compiled)—because memory can’t be effectively executed at the same time it’s being read from and written to.
System Coprocessor Integrity Protection
Coprocessor firmware handles many critical system tasks—for example, the Secure Enclave, the image sensor processor, and the motion coprocessor. Therefore its security is a key part of the security of the overall system. To prevent modification of coprocessor firmware, Apple uses a mechanism called System Coprocessor Integrity Protection (SCIP).
SCIP works much like Kernel Integrity Protection (KIP): At boot time, iBoot loads each coprocessor’s firmware into a protected memory region, one that’s reserved and separate from the KIP region. iBoot configures each coprocessor’s memory unit to prevent:
Executable mappings outside its part of the protected memory region
Writeable mappings inside its part of the protected memory region
Also at boot time, to configure SCIP for the Secure Enclave, the Secure Enclave operating system is used. After the boot process is complete, the hardware used to enable SCIP is locked to prevent reconfiguration.
Pointer Authentication Codes
Pointer Authentication Codes (PACs) are used to protect against exploitation of memory corruption bugs. System software and built-in apps use PAC to prevent modification of function pointers and return addresses (code pointers). PAC uses five secret 128-bit values to sign kernel instructions and data, and each user space process has its own B keys. Items are salted and signed as indicated below.
Function Return Address
Block Invocation Function
Objective-C Method Cache
Storage address + Class + Selector
C++ V-Table Entries
Storage address + Hash (mangled method name)
Computed Goto Label
Hash (function name)
Kernel Thread State
User Thread State Registers
C++ V-Table Pointers
The signature value is stored in the unused padding bits at the top of the 64-bit pointer. The signature is verified before use, and the padding is restored to ensure a functioning pointer address. Failure to verify results in an abort. This verification increases the difficulty of many attacks, such as a return-oriented programming (ROP) attack, which attempts to trick the device into executing existing code maliciously by manipulating function return addresses stored on the stack.
Page Protection Layer
Page Protection Layer (PPL) in iOS, iPadOS, and watchOS prevents user space code from being modified after code signature verification is complete. Building on Kernel Integrity Protection and Fast Permission Restrictions, PPL manages the page table permission overrides to make sure only the PPL can alter protected pages containing user code and page tables. The system provides a massive reduction in attack surface by supporting systemwide code integrity enforcement, even in the face of a compromised kernel. This protection isn’t offered in macOS because PPL is only applicable on systems where all executed code must be signed.