arm64e.x1: Apple's Checked Pointer Arithmetic Slice

What is arm64e.x1? A new Mach-O slice, CPU subtype 12, that Apple’s iOS 27 RC release notes introduced on September 11 in one paragraph: it “introduces additional hardware security and performance instructions, including CPA2 for stronger MIE protection,” on iPhones with A20 Pro or later, Macs with M6 or later, and Apple Watch models with S11 or later.¹ In that slice, Apple clang 21 compiles ordinary pointer arithmetic to the Arm addpt instruction, which poisons a pointer whose arithmetic overflows into its top byte, where the memory tag lives, instead of letting the computation present a tag the hardware would accept. Xcode 27 adds the slice with one build setting and gates run-time enforcement behind the Enhanced Security entitlement and two entitlements beneath it.²³

TL;DR: The paragraph reached the iOS and watchOS 27 RC notes by my watcher’s 10:01 a.m. PT check and the macOS notes by 11:12 a.m., with a “Learn more” link that points at an internal Apple drafts host; the public Enhanced Security article does not mention the slice yet.¹⁴⁵ The Xcode 27 RC already ships everything: the subtype constant, a compiler that targets apple-a20 with +cpa, the build setting, and a reference document that spells out the four switches.⁶²⁷³ Announced hardware: iPhone 18 Pro and iPhone Duo (A20 Pro), the M6 Mac mini, Apple Watch Series 12 and Ultra 4 (S11); the iPhone 17 family is not on the list.¹⁹ Build all three slices, keep pointer authentication on, and expect crashes far from the arithmetic that caused them.

What appeared, and where

The iOS and iPadOS 27 RC release notes gained a section headed Hardware Security, with the paragraph under its New Features subhead. Its text, in full:

arm64e.x1 introduces additional hardware security and performance instructions, including CPA2 for stronger MIE protection. Devices with support for arm64e.x1 include iPhone models with A20 Pro or later chips, Mac computers with M6 or later chips, and Apple Watch models with S11 or later chips. You can access arm64e.x1 and CPA2 in Xcode through the enhanced security pane and a build setting. Learn more in the Enhanced Security article. (152103975)¹

The watchOS 27 RC notes gained the same paragraph in the same check. The macOS 27 RC notes had not at 10:02 a.m. PT, although the paragraph lists Macs with M6 or later; by 11:12 a.m. PT they carried it too, with the same link.⁴ My watcher fetches those three pages every few minutes; all three had been unchanged since September 9.

Two details in that paragraph deserve attention. The “Learn more” link does not go to the public documentation. The page’s data names its target as https://docs.devpubs.apple.com/drafts/f16-dspector-161940504-rapid-isa-adoption-documentation/documentation/xcode/enabling-enhanced-security-for-your-app, a host that does not resolve from outside Apple.¹ And the public article at the matching path, Enabling enhanced security for your app, does not mention arm64e.x1 or CPA2 as of 10:40 a.m. PT; it still documents the capability’s build settings, from ENABLE_POINTER_AUTHENTICATION to CLANG_ENABLE_STACK_ZERO_INIT.⁵

The Xcode 27 RC release notes have carried a matching item under Enhanced Security since the RC shipped on September 9, and it is the one that names the mechanism:

arm64e.x1 or the Hardware-Checked Pointer Arithmetic slice contains the Check for Overflow of Pointer Arithmetic entitlement by checking for overflow into memory tags, providing additional protection on top of Memory Integrity Enforcement. (152104701)¹⁰

The slice was not a secret. On September 9 at 1:40 p.m. PT, the researcher who posts as Longhorn wrote that “Apple M6/A20 ship with FEAT_CPA2 - checked pointer arithmetic - and there’s a new executable type for it” and quoted a sentence that turns out to come from a document inside Xcode.¹¹ The iOS and watchOS notes caught up two days later.

The slice, in the SDK and the compiler

The iOS SDK in Xcode 27.0 (build 27A266a) defines the subtype in mach/machine.h:

#define CPU_SUBTYPE_ARM64E              ((cpu_subtype_t) 2)
/* The non-e x1 is defined in other tooling, but it's otherwise unused. */
#define CPU_SUBTYPE_ARM64_X1            ((cpu_subtype_t) 3)
#define CPU_SUBTYPE_ARM64E_X1           ((cpu_subtype_t) 12)

The comment above the helper macro says where the taxonomy is going: “The current PAC slices include ARM64E and ARM64E_X1. Future slices may continue the convention.”⁶

Apple clang 21.0.0 (clang-2100.3.34.2), the compiler in that Xcode, accepts -arch arm64e.x1 and treats it as a different CPU. With -### it reports -target-cpu apple-a20 and a feature list that includes +cpa, +mte, +pauth, +pauth-lr, and +fpac. Plain -arch arm64e reports -target-cpu apple-a12 and no +cpa.² The object file’s header records the subtype as E.X1, and lipo -info calls the architecture arm64e.x1.

The difference is one mnemonic. Take a function that adds an index to a pointer:

int *g(int *p, long i) { return p + i; }

Built with -O2 for arm64e, the body is one add and a return. Built for arm64e.x1, the add becomes addpt:

-arch arm64e:
    add   x0, x0, x1, lsl #2
    ret

-arch arm64e.x1:
    addpt x0, x0, x1, lsl #2
    ret

The build needed no flag; selecting the architecture turns checked arithmetic on.² The flag exists for the other direction and for other slices. Clang’s help lists -fchecked-pointer-arithmetic, described as “Enable checked pointer arithmetic, with software sequences if necessary,” and -fno-checked-pointer-arithmetic.² With the flag, plain arm64e and arm64 get a software sequence: an ordinary add, an exclusive-or of base and result, a test of the top 10 bits, [63:54], against 0xffc0000000000000, and, when they differ, a movk that writes 0xc8a2 into the pointer’s top 16 bits, which makes it non-canonical. With -fno-checked-pointer-arithmetic, arm64e.x1 goes back to a plain add.²

What CPA2 checks

Apple ships a reference document inside Xcode 27 for its coding assistant, and it explains the check better than the release notes do. Its first sentence: “Checked pointer arithmetic makes hardware supporting the FEAT_CPA2 extension detect when a pointer computation overflows out of the address bits into the upper bits of the pointer.” The document says why the top byte matters: “Overflowing into them is what lets arithmetic walk from one object into another while still presenting a tag the hardware accepts.” Then: “Detection happens in two places: explicit arithmetic poisons its result, and every load and store checks the addition it performs as part of its addressing mode.”³

The comparison is between top bytes. “The check compares the result’s top byte, bits [63:56], against the base operand’s top byte. That byte carries the 4-bit Memory Tagging Extension (MTE) tag in bits [59:56] when MTE is enabled.” The hardware poisons a pointer that fails the check, and that poison is what the software sequence above imitates: “A poisoned pointer is deliberately non-canonical, so the next dereference takes a level-0 translation fault, delivered as EXC_ARM_CPA_FAIL (0x108) with ESR 0x92000004 (read) or 0x92000044 (write).”³

The instruction comes from Arm. LLVM’s patch adding assembler support, merged on November 30, 2023, describes the Checked Pointer Arithmetic Extension, FEAT_CPA, as announced with the Armv9.5-A architecture, and adds the scalar instructions ADDPT, SUBPT, MADDPT, and MSUBPT plus vector forms.¹² Apple’s notes and its reference document both say CPA2, the enabling extension the hardware needs to support, and the reference document’s definition is the one quoted above.³

The “MIE” in Apple’s paragraph is Memory Integrity Enforcement, which Apple’s security team announced on September 9, 2025 as “our comprehensive memory safety defense for Apple platforms,” “built right into Apple hardware and software in all models of iPhone 17 and iPhone Air,” on top of the Enhanced Memory Tagging Extension (EMTE) Apple developed with Arm.⁸ That post told developers they could “begin testing this powerful protection for their app, including EMTE on hardware that supports it, using the Enhanced Security settings in Xcode.”⁸ CPA2 closes one specific gap in tagging. Tagging compares the tag in a pointer’s top byte with the tag of the memory it touches, so a pointer that merely crosses into a neighboring allocation without disturbing its top byte is tagging’s case: the tags differ, the access faults. Arithmetic that overflows into the top byte is the case tagging cannot see, because it can “manufacture a pointer whose tag matches a different allocation,” and “without this check, that overflow is how an attacker would defeat tagging,” in the reference document’s words.³

The four switches in Xcode 27

The reference document is blunt: “Four things must be enabled on an app target. Miss one and there is no protection.”³ They are:

1. The build setting ENABLE_HARDWARE_CHECKED_POINTER_ARITHMETIC_SLICE = YES, shown in Build Settings under Security as “Enable Hardware-Checked Pointer Arithmetic Slice.” It exists in the Xcode 27 RC’s build-system specification.³⁷
2. The Enhanced Security entitlement, com.apple.security.hardened-process, added through the capability in Signing & Capabilities.
3. Hardware memory tagging, com.apple.security.hardened-process.checked-allocations, the Memory Safety option “Enable Hardware Memory Tagging.”
4. The enforcement entitlement, com.apple.security.hardened-process.checked-allocations.enforce-checked-pointer-arithmetic-overflow, the option “Enforce Checking for Overflow of Pointer Arithmetic.”

“Row 4 is a sub-option of row 3, and row 3 of row 2.”³ Tagging is required because the top byte has to hold something worth comparing.

The build setting does one thing: it “appends arm64e.x1 to ARCHS_STANDARD.” That has a prerequisite of its own: “The setting has no effect if ARCHS is overridden to something not based on ARCHS_STANDARD.” And a manual entitlements file needs one more key: “Row 2 also needs com.apple.security.hardened-process.enhanced-security-version-string = 2; Xcode writes that key when you add the capability, so write it yourself if you edit the entitlements file directly.” The document’s measured table for an iOS target is the one to memorize.³

Use the last row. With the slice on and pointer authentication off, a device without CPA2 falls back to plain arm64 and loses pointer authentication it would otherwise have had.³ Verify the result the way the document does:

lipo -archs MyApp.app/MyApp        # expect: arm64 arm64e arm64e.x1

Three more facts from the same document belong next to the table. “__arm64e_x1__ is a predefined macro, for code that must be compiled differently for the arm64e.x1 slice.” The simulator needs nothing: “Simulator SDKs define no arm64e.x1 architecture, so the build system drops it from a simulator build’s effective architectures exactly as it does arm64e.” And Apple describes the run-time overhead as low and the cost as size: “The cost is binary size: a third slice.”³ Libraries and frameworks take the build setting only; the system grants entitlements per process, from the main executable. And a library that ships only arm64e still benefits when an enforcing app loads it: “load/store instructions in the library will still be checked.”³

Code changes: “Generally none. The compiler emits the checked instructions in the arm64e.x1 slice, and the hardware enforces them once the entitlements in ‘How to Enable’ are in place.”³ The exceptions are the patterns whose arithmetic disturbs the top byte, which the document lists: a difference between pointers into two allocations, an offset carried past the end of an object, arithmetic on a NULL base, and integer-typed pointers in arithmetic. Its stability note is one sentence: “code with latent pointer-arithmetic bugs will crash.” The document warns that the poisoning instruction and the faulting dereference “may be in different functions, files, or libraries.”³ Xcode warns at build time if the enforcement entitlement is set on a target that does not build the slice; the document calls that warning “the only signal that the configuration is incomplete.”³

Who has the hardware

Apple’s list is chips, and the September releases map them to products. A20 Pro is in iPhone 18 Pro and iPhone 18 Pro Max, “all powered by A20 Pro,” and in iPhone Duo, “Powered by the new A20 Pro.”⁹ S11 is the chip in Apple Watch Series 12 and Apple Watch Ultra 4.⁹ Apple announced M6 on August 25 in the Mac mini, in the release titled “Apple unveils a more powerful Mac mini featuring the all-new M6 and M5 Pro.”⁹ Announced is not in hand: Apple’s dates put iPhone 18 Pro and the new watches in stores on September 18, the Mac mini in stores on September 22, and iPhone Duo on October 23.⁹ The reference document’s own platform list names iOS on A20 Pro and watchOS on S11 and says nothing about the Mac, which the release notes include.³ The A19 and A19 Pro chips in iPhone 17 and iPhone Air run Memory Integrity Enforcement but are not in the arm64e.x1 list, so the software sequence, not addpt, is what those phones would run if a build enabled the flag for arm64e.¹⁸

For anyone building for iPhone Duo, the slice is the first Duo-relevant toolchain change that does not wait for the iOS 27.1 SDK. It is in the Xcode 27 RC today, and a Duo, with its A20 Pro, is on the enforcement list from the first day it ships.

What I would do

Turn on the last row of the table on any app that already adopts Enhanced Security, and add the enforcement entitlement on a branch first. Once the hardware arrives, treat every EXC_ARM_CPA_FAIL as a bug report about pointer arithmetic, and look for the poisoning site, not the crash site. Leave the flag alone on arm64e: the software sequence costs instructions on every pointer addition, and the slice is the better bet. Until Apple publishes the article its release notes link to, the reference document inside Xcode is the most complete description it has shipped.

Key Takeaways

For iOS and macOS engineers:

• arm64e.x1 is Mach-O CPU subtype 12; clang targets apple-a20 with +cpa for it and compiles pointer arithmetic to addpt.
• Enforcement needs four switches: the slice build setting, Enhanced Security, hardware memory tagging, and the overflow entitlement. Build arm64 arm64e arm64e.x1.

For security and platform leads:

• Under enforcement, checked arithmetic instructions compare the result’s top byte with the base’s and poison on mismatch, closing the arithmetic bypass against memory tagging; load and store address calculations receive checks too, even in plain arm64e libraries loaded by an enforcing app.
• Announced compatible hardware: A20 Pro (iPhone 18 Pro, iPhone Duo), M6 (Mac mini), S11 (Watch Series 12 and Ultra 4). iPhone 17 is not on the list; the devices reach stores from September 18.

For anyone tracking Apple’s documentation:

• The release-notes paragraph links to an internal drafts host and the public article lags it; the Xcode 27 RC’s bundled reference is the complete source for now.

FAQ

Does arm64e.x1 replace arm64e?

No. Apple’s own measured table shows the recommended configuration as arm64 arm64e arm64e.x1, and the reference document says a target that builds the x1 slice without pointer authentication ships no arm64e slice at all, so older devices lose pointer authentication.³

Do I need to change code?

Usually not. The compiler emits the checked instructions and the hardware enforces them once the entitlements are in place. Code whose pointer arithmetic disturbs a pointer’s top byte, such as differences between pointers into different allocations, offsets carried far past the end of an object, or arithmetic on a NULL base, faults under enforcement, which is the point; Apple’s reference document says such code “will crash.”³

Which devices enforce it?

Per the release notes: iPhone models with A20 Pro or later, Macs with M6 or later, and Apple Watch models with S11 or later.¹ On other devices the loader does not select the slice, and nothing changes.

Is CPA2 the same as Arm’s FEAT_CPA?

No. Arm’s feature registry lists FEAT_CPA as “Instruction-only Checked Pointer Arithmetic” and FEAT_CPA2 as “Checked Pointer Arithmetic”: the first supplies the ADDPT family of instructions that clang emits, and the second is the hardware support for the check itself.¹³¹² Apple names CPA2 as the requirement, and its reference document says of A20 Pro and S11 that “Both chips support FEAT_CPA2, which the arm64e.x1 slice targets.”³

Sources