arm64e.x1: Apples Slice für geprüfte Zeigerarithmetik

Was ist arm64e.x1? Ein neues Mach-O-Slice mit CPU-Subtype 12, das Apple in den Release Notes zum iOS 27 RC am 11. September in einem einzigen Absatz eingeführt hat: Es „führt zusätzliche Hardware-Sicherheits- und Performance-Instruktionen ein, darunter CPA2 für stärkeren MIE-Schutz” – auf iPhones mit A20 Pro oder neuer, Macs mit M6 oder neuer und Apple-Watch-Modellen mit S11 oder neuer.¹ In diesem Slice übersetzt Apple clang 21 gewöhnliche Zeigerarithmetik in die Arm-Instruktion addpt, die einen Zeiger vergiftet, sobald dessen Arithmetik in das oberste Byte überläuft, wo das Memory-Tag sitzt, statt die Berechnung ein Tag vorlegen zu lassen, das die Hardware akzeptieren würde. Xcode 27 fügt das Slice über eine einzige Build-Einstellung hinzu und knüpft die Durchsetzung zur Laufzeit an das Enhanced-Security-Entitlement sowie zwei darunterliegende Entitlements.²³

TL;DR: Bis zur 10:01-Uhr-Prüfung meines Watchers (PT) war der Absatz in den RC-Notes zu iOS und watchOS 27 angekommen, bis 11:12 Uhr auch in denen zu macOS – mit einem „Learn more”-Link, der auf einen internen Apple-Entwurfshost zeigt; der öffentliche Enhanced-Security-Artikel erwähnt das Slice bislang nicht.¹⁴⁵ Der Xcode 27 RC liefert bereits alles: die Subtype-Konstante, einen Compiler, der apple-a20 mit +cpa anzielt, die Build-Einstellung und ein Referenzdokument, das die vier Schalter ausbuchstabiert.⁶²⁷³ Angekündigte Hardware: iPhone 18 Pro und iPhone Duo (A20 Pro), der M6-Mac-mini, Apple Watch Series 12 und Ultra 4 (S11); die iPhone-17-Familie steht nicht auf der Liste.¹⁹ Bauen Sie alle drei Slices, lassen Sie Pointer Authentication eingeschaltet, und rechnen Sie mit Abstürzen weit entfernt von der Arithmetik, die sie verursacht hat.

Update, 17. September: Eine Upload-Sperre für den App Store auf macOS 26.6

Apple hat zwischen meinen Abrufen des Dokumentations-JSON vom 16. und 17. September ein bekanntes Problem in den Abschnitt Enhanced Security der Release Notes zu Xcode 27 aufgenommen: „Apps with Hardware-Checked Pointer Arithmetic Slice feature enabled cannot be uploaded to the App Store on macOS Tahoe 26.6 with Xcode automatic signing enabled.“ (Apps mit aktivierter Funktion Hardware-Checked Pointer Arithmetic Slice lassen sich auf macOS Tahoe 26.6 mit aktivierter automatischer Signierung von Xcode nicht in den App Store hochladen.) Der Workaround, den Apple nennt: „Distribute with macOS 27 and Xcode 27 or use manual signing.“ (Mit macOS 27 und Xcode 27 ausliefern oder manuelle Signierung verwenden.)¹⁴ Ein Build mit dem arm64e.x1-Slice hat also auf dem minimalen Host, den Xcode 27 unterstützt, einen Preis bei der Distribution: Ein Mac, der noch auf Tahoe 26.6 läuft, dem Minimum, das Xcode 27 voraussetzt, kann diesen Build mit automatischer Signierung nicht hochladen. Manuelle Signierung oder ein Host mit macOS 27 räumt das aus, laut Apples Note; ich habe keinen Rechner mit macOS 27 und habe keinen der beiden Wege ausprobiert.¹⁴

Was auftauchte, und wo

Die Release Notes zu iOS und iPadOS 27 RC erhielten einen Abschnitt mit der Überschrift Hardware Security; der Absatz steht dort unter der Zwischenüberschrift New Features. Sein Text im Wortlaut:

arm64e.x1 führt zusätzliche Hardware-Sicherheits- und Performance-Instruktionen ein, darunter CPA2 für stärkeren MIE-Schutz. Zu den Geräten mit Unterstützung für arm64e.x1 zählen iPhone-Modelle mit A20 Pro oder neueren Chips, Mac-Computer mit M6 oder neueren Chips und Apple-Watch-Modelle mit S11 oder neueren Chips. In Xcode können Sie über das Enhanced-Security-Panel und eine Build-Einstellung auf arm64e.x1 und CPA2 zugreifen. Mehr dazu im Artikel zu Enhanced Security. (152103975)¹

Die RC-Notes zu watchOS 27 erhielten denselben Absatz in derselben Prüfung. Die RC-Notes zu macOS 27 hatten ihn um 10:02 Uhr PT noch nicht, obwohl der Absatz Macs mit M6 oder neuer ausdrücklich aufführt; um 11:12 Uhr PT trugen auch sie ihn, mit demselben Link.⁴ Mein Watcher ruft diese drei Seiten alle paar Minuten ab; alle drei waren seit dem 9. September unverändert geblieben.

Zwei Details dieses Absatzes verdienen Aufmerksamkeit. Der „Learn more”-Link führt nicht zur öffentlichen Dokumentation. Als Ziel nennen die Daten der Seite https://docs.devpubs.apple.com/drafts/f16-dspector-161940504-rapid-isa-adoption-documentation/documentation/xcode/enabling-enhanced-security-for-your-app, einen Host, der sich von außerhalb Apples nicht auflösen lässt.¹ Und der öffentliche Artikel unter dem passenden Pfad, Enhanced Security für Ihre App aktivieren, erwähnt mit Stand 10:40 Uhr PT weder arm64e.x1 noch CPA2; er dokumentiert nach wie vor die Build-Einstellungen dieser Capability, von ENABLE_POINTER_AUTHENTICATION bis CLANG_ENABLE_STACK_ZERO_INIT.⁵

Die Release Notes zum Xcode 27 RC führen unter Enhanced Security seit dem Erscheinen des RC am 9. September einen passenden Eintrag – und dieser benennt den Mechanismus:

arm64e.x1 bzw. das Hardware-Checked-Pointer-Arithmetic-Slice setzt das Entitlement Check for Overflow of Pointer Arithmetic um, indem es auf Überlauf in Memory-Tags prüft, und bietet damit zusätzlichen Schutz über Memory Integrity Enforcement hinaus. (152104701)¹⁰

Ein Geheimnis war das Slice nicht. Am 9. September um 13:40 Uhr PT schrieb der Forscher, der als Longhorn postet, „Apple M6/A20 ship with FEAT_CPA2 - checked pointer arithmetic - and there’s a new executable type for it”, und zitierte einen Satz, der sich als Zitat aus einem Dokument innerhalb von Xcode herausstellte.¹¹ Die Notes zu iOS und watchOS zogen zwei Tage später nach.

Das Slice im SDK und im Compiler

Das iOS SDK in Xcode 27.0 (Build 27A266a) definiert den 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)

Der Kommentar über dem Hilfsmakro verrät, wohin die Systematik führt: „Zu den aktuellen PAC-Slices zählen ARM64E und ARM64E_X1. Künftige Slices können die Konvention fortführen.”⁶

Apple clang 21.0.0 (clang-2100.3.34.2), der Compiler in diesem Xcode, akzeptiert -arch arm64e.x1 und behandelt es als andere CPU. Mit -### meldet er -target-cpu apple-a20 und eine Feature-Liste, die +cpa, +mte, +pauth, +pauth-lr und +fpac enthält. Das schlichte -arch arm64e meldet -target-cpu apple-a12 und kein +cpa.² Der Header der Objektdatei verzeichnet den Subtype als E.X1, und lipo -info nennt die Architektur arm64e.x1.

Der Unterschied ist ein einziges Mnemonic. Nehmen Sie eine Funktion, die einen Index auf einen Zeiger addiert:

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

Mit -O2 für arm64e gebaut, besteht der Rumpf aus einem Add und einem Return. Für arm64e.x1 gebaut, wird aus dem Add ein addpt:

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

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

Der Build brauchte kein Flag; die Wahl der Architektur schaltet die geprüfte Arithmetik ein.² Das Flag existiert für die Gegenrichtung und für andere Slices. Die Hilfe von clang führt -fchecked-pointer-arithmetic auf, beschrieben als „Enable checked pointer arithmetic, with software sequences if necessary”, sowie -fno-checked-pointer-arithmetic.² Mit dem Flag erhalten schlichtes arm64e und arm64 eine Software-Sequenz: ein gewöhnliches add, ein Exklusiv-Oder aus Basis und Ergebnis, einen Test der obersten 10 Bits, [63:54], gegen 0xffc0000000000000 und, falls sie sich unterscheiden, ein movk, das 0xc8a2 in die obersten 16 Bits des Zeigers schreibt und ihn damit nicht-kanonisch macht. Mit -fno-checked-pointer-arithmetic fällt arm64e.x1 auf ein schlichtes add zurück.²

Was CPA2 prüft

Apple liefert innerhalb von Xcode 27 ein Referenzdokument für seinen Coding-Assistenten mit, und dieses erklärt die Prüfung besser als die Release Notes. Sein erster Satz: „Geprüfte Zeigerarithmetik sorgt dafür, dass Hardware mit Unterstützung für die FEAT_CPA2-Erweiterung erkennt, wenn eine Zeigerberechnung aus den Adressbits in die oberen Bits des Zeigers überläuft.” Warum das oberste Byte zählt, sagt das Dokument ebenfalls: „Der Überlauf in diese Bits ist es, der Arithmetik von einem Objekt in ein anderes wandern lässt und dabei weiterhin ein Tag vorlegt, das die Hardware akzeptiert.” Und weiter: „Die Erkennung findet an zwei Stellen statt: Explizite Arithmetik vergiftet ihr Ergebnis, und jedes Load und Store prüft die Addition, die es im Rahmen seines Adressierungsmodus durchführt.”³

Verglichen werden oberste Bytes. „Die Prüfung vergleicht das oberste Byte des Ergebnisses, Bits [63:56], mit dem obersten Byte des Basisoperanden. Dieses Byte trägt bei aktivierter MTE das 4 Bit breite Tag der Memory Tagging Extension (MTE) in den Bits [59:56].” Die Hardware vergiftet einen Zeiger, der die Prüfung nicht besteht, und genau dieses Vergiften ahmt die obige Software-Sequenz nach: „Ein vergifteter Zeiger ist absichtlich nicht-kanonisch, sodass die nächste Dereferenzierung einen Level-0-Translation-Fault auslöst, zugestellt als EXC_ARM_CPA_FAIL (0x108) mit ESR 0x92000004 (Lesen) bzw. 0x92000044 (Schreiben).”³

Die Instruktion stammt von Arm. Der LLVM-Patch, der Assembler-Unterstützung hinzufügt und am 30. November 2023 gemergt wurde, beschreibt die Checked Pointer Arithmetic Extension, FEAT_CPA, als mit der Architekturversion Armv9.5-A angekündigt und ergänzt die Skalarinstruktionen ADDPT, SUBPT, MADDPT und MSUBPT nebst Vektorformen.¹² Apples Notes wie auch sein Referenzdokument sprechen von CPA2, der freischaltenden Erweiterung, die die Hardware unterstützen muss; die Definition des Referenzdokuments ist die oben zitierte.³

Das „MIE” in Apples Absatz steht für Memory Integrity Enforcement, das Apples Sicherheitsteam am 9. September 2025 als „unsere umfassende Verteidigung für Speichersicherheit auf Apple-Plattformen” ankündigte, „direkt in Apple-Hardware und -Software eingebaut in allen Modellen von iPhone 17 und iPhone Air”, aufbauend auf der Enhanced Memory Tagging Extension (EMTE), die Apple gemeinsam mit Arm entwickelt hat.⁸ Jener Beitrag teilte Entwicklern mit, sie könnten „mit den Enhanced-Security-Einstellungen in Xcode beginnen, diesen starken Schutz für ihre App zu testen, einschließlich EMTE auf Hardware, die es unterstützt”.⁸ CPA2 schließt eine ganz bestimmte Lücke im Tagging. Tagging vergleicht das Tag im obersten Byte eines Zeigers mit dem Tag des Speichers, den er berührt; ein Zeiger, der lediglich in eine benachbarte Allokation hinüberläuft, ohne sein oberstes Byte anzutasten, ist deshalb der Fall des Taggings: Die Tags unterscheiden sich, der Zugriff schlägt fehl. Arithmetik, die in das oberste Byte überläuft, ist hingegen der Fall, den Tagging nicht sehen kann, denn sie kann „einen Zeiger fabrizieren, dessen Tag zu einer anderen Allokation passt”, und „ohne diese Prüfung ist genau dieser Überlauf der Weg, auf dem ein Angreifer das Tagging aushebeln würde”, wie es im Referenzdokument heißt.³

Die vier Schalter in Xcode 27

Das Referenzdokument wird deutlich: „Auf einem App-Target müssen vier Dinge aktiviert sein. Fehlt eines, gibt es keinen Schutz.”³ Es sind:

1. Die Build-Einstellung ENABLE_HARDWARE_CHECKED_POINTER_ARITHMETIC_SLICE = YES, in den Build Settings unter Security als „Enable Hardware-Checked Pointer Arithmetic Slice” ausgewiesen. Sie existiert in der Build-System-Spezifikation des Xcode 27 RC.³⁷
2. Das Enhanced-Security-Entitlement com.apple.security.hardened-process, hinzugefügt über die Capability in Signing & Capabilities.
3. Hardware-Memory-Tagging, com.apple.security.hardened-process.checked-allocations, die Memory-Safety-Option „Enable Hardware Memory Tagging”.
4. Das Durchsetzungs-Entitlement com.apple.security.hardened-process.checked-allocations.enforce-checked-pointer-arithmetic-overflow, die Option „Enforce Checking for Overflow of Pointer Arithmetic”.

„Zeile 4 ist eine Unteroption von Zeile 3, und Zeile 3 eine von Zeile 2.”³ Tagging ist erforderlich, weil das oberste Byte etwas enthalten muss, das sich zu vergleichen lohnt.

Die Build-Einstellung tut genau eines: Sie „hängt arm64e.x1 an ARCHS_STANDARD an”. Das hat seinerseits eine Voraussetzung: „Die Einstellung bleibt wirkungslos, wenn ARCHS auf etwas überschrieben wird, das nicht auf ARCHS_STANDARD beruht.” Und eine handgeschriebene Entitlements-Datei braucht einen weiteren Schlüssel: „Zeile 2 benötigt zusätzlich com.apple.security.hardened-process.enhanced-security-version-string = 2; Xcode schreibt diesen Schlüssel, wenn Sie die Capability hinzufügen – schreiben Sie ihn also selbst, wenn Sie die Entitlements-Datei direkt bearbeiten.” Die gemessene Tabelle des Dokuments für ein iOS-Target ist die, die man sich einprägen sollte.³

Nehmen Sie die letzte Zeile. Ist das Slice eingeschaltet und Pointer Authentication aus, fällt ein Gerät ohne CPA2 auf schlichtes arm64 zurück und verliert die Pointer Authentication, die es sonst gehabt hätte.³ Prüfen Sie das Ergebnis so, wie es das Dokument tut:

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

Drei weitere Fakten aus demselben Dokument gehören neben die Tabelle. „__arm64e_x1__ ist ein vordefiniertes Makro für Code, der für das arm64e.x1-Slice anders kompiliert werden muss.” Der Simulator braucht nichts: „Simulator-SDKs definieren keine arm64e.x1-Architektur, deshalb streicht das Build-System sie aus den effektiven Architekturen eines Simulator-Builds – genau so, wie es das mit arm64e tut.” Den Laufzeit-Overhead beschreibt Apple als gering, die Kosten als Größe: „Der Preis ist die Binärgröße: ein drittes Slice.”³ Bibliotheken und Frameworks brauchen nur die Build-Einstellung; Entitlements vergibt das System pro Prozess, ausgehend von der Hauptausführungsdatei. Und eine Bibliothek, die ausschließlich arm64e mitbringt, profitiert dennoch, wenn eine durchsetzende App sie lädt: „Load-/Store-Instruktionen in der Bibliothek werden trotzdem geprüft.”³

Codeänderungen: „In der Regel keine. Der Compiler gibt die geprüften Instruktionen im arm64e.x1-Slice aus, und die Hardware setzt sie durch, sobald die Entitlements aus ‚How to Enable’ vorhanden sind.”³ Ausnahmen sind jene Muster, deren Arithmetik das oberste Byte antastet; das Dokument zählt sie auf: eine Differenz zwischen Zeigern in zwei verschiedene Allokationen, ein über das Ende eines Objekts hinaus mitgeführter Offset, Arithmetik auf einer NULL-Basis und ganzzahlig typisierte Zeiger in Berechnungen. Der Hinweis zur Stabilität ist ein einziger Satz: „Code mit latenten Fehlern in der Zeigerarithmetik wird abstürzen.” Das Dokument warnt, die vergiftende Instruktion und die fehlschlagende Dereferenzierung „können in verschiedenen Funktionen, Dateien oder Bibliotheken liegen”.³ Xcode warnt zur Build-Zeit, wenn das Durchsetzungs-Entitlement auf einem Target gesetzt ist, das das Slice nicht baut; das Dokument nennt diese Warnung „das einzige Signal dafür, dass die Konfiguration unvollständig ist”.³

Wer die Hardware hat

Apples Liste nennt Chips, und die September-Ankündigungen ordnen sie Produkten zu. A20 Pro steckt in iPhone 18 Pro und iPhone 18 Pro Max, „all powered by A20 Pro”, und in iPhone Duo, „Powered by the new A20 Pro”.⁹ S11 ist der Chip in Apple Watch Series 12 und Apple Watch Ultra 4.⁹ M6 kündigte Apple am 25. August im Mac mini an, in der Mitteilung mit dem Titel „Apple unveils a more powerful Mac mini featuring the all-new M6 and M5 Pro”.⁹ Angekündigt heißt nicht in der Hand: Nach Apples Terminen stehen iPhone 18 Pro und die neuen Uhren am 18. September im Handel, der Mac mini am 22. September und iPhone Duo am 23. Oktober.⁹ Die eigene Plattformliste des Referenzdokuments nennt iOS auf A20 Pro und watchOS auf S11 und schweigt zum Mac, den die Release Notes einschließen.³ Die Chips A19 und A19 Pro in iPhone 17 und iPhone Air führen Memory Integrity Enforcement aus, stehen aber nicht auf der arm64e.x1-Liste; auf diesen Telefonen liefe deshalb die Software-Sequenz und nicht addpt, sollte ein Build das Flag für arm64e einschalten.¹⁸ Für Macs behandelt Xcode 27 Drops Intel die andere ARCHS_STANDARD-Änderung dieses Releases: Ab Deployment-Target 27.0 entfällt x86_64.

Für alle, die für iPhone Duo entwickeln, ist das Slice die erste Duo-relevante Toolchain-Änderung, die nicht auf das iOS-27.1-SDK wartet. Sie steckt heute schon im Xcode 27 RC, und ein Duo steht mit seinem A20 Pro vom ersten Verkaufstag an auf der Durchsetzungsliste. Bereiten Sie Ihre App auf iPhone Duo vor führt eine echte App durch jede Pose und bis zur Einreichung.

Was ich tun würde

Schalten Sie bei jeder App, die Enhanced Security bereits übernommen hat, die letzte Zeile der Tabelle ein, und fügen Sie das Durchsetzungs-Entitlement zunächst in einem Branch hinzu. Sobald die Hardware da ist, behandeln Sie jedes EXC_ARM_CPA_FAIL als Fehlerbericht über Zeigerarithmetik und suchen Sie die Stelle der Vergiftung, nicht die des Absturzes. Auf arm64e lassen Sie das Flag in Ruhe: Die Software-Sequenz kostet Instruktionen bei jeder Zeigeraddition, und das Slice ist die bessere Wette. Bis Apple den Artikel veröffentlicht, auf den seine Release Notes verlinken, bleibt das Referenzdokument in Xcode die vollständigste Beschreibung, die der Konzern ausgeliefert hat.

Die wichtigsten Erkenntnisse

Für iOS- und macOS-Entwickler: - arm64e.x1 ist Mach-O-CPU-Subtype 12; clang zielt dafür mit +cpa auf apple-a20 und übersetzt Zeigerarithmetik in addpt. - Die Durchsetzung braucht vier Schalter: die Build-Einstellung für das Slice, Enhanced Security, Hardware-Memory-Tagging und das Überlauf-Entitlement. Bauen Sie arm64 arm64e arm64e.x1.

Für Security- und Plattformverantwortliche: - Unter Durchsetzung vergleichen geprüfte Arithmetikinstruktionen das oberste Byte des Ergebnisses mit dem der Basis und vergiften bei Abweichung; damit schließt sich der arithmetische Umweg um das Memory-Tagging. Auch Adressberechnungen von Load und Store werden geprüft, selbst in schlichten arm64e-Bibliotheken, die eine durchsetzende App lädt. - Angekündigte kompatible Hardware: A20 Pro (iPhone 18 Pro, iPhone Duo), M6 (Mac mini), S11 (Watch Series 12 und Ultra 4). iPhone 17 steht nicht auf der Liste; die Geräte kommen ab dem 18. September in den Handel.

Für alle, die Apples Dokumentation verfolgen: - Der Absatz in den Release Notes verlinkt auf einen internen Entwurfshost, und der öffentliche Artikel hinkt hinterher; die mitgelieferte Referenz des Xcode 27 RC ist vorerst die vollständige Quelle.

Häufige Fragen

Ersetzt arm64e.x1 das bisherige arm64e?

Nein. Apples eigene gemessene Tabelle weist als empfohlene Konfiguration arm64 arm64e arm64e.x1 aus, und das Referenzdokument hält fest: Ein Target, das das x1-Slice ohne Pointer Authentication baut, liefert überhaupt kein arm64e-Slice aus – ältere Geräte verlieren damit die Pointer Authentication.³

Muss ich Code ändern?

Meistens nicht. Der Compiler gibt die geprüften Instruktionen aus, und die Hardware setzt sie durch, sobald die Entitlements vorhanden sind. Code, dessen Zeigerarithmetik das oberste Byte eines Zeigers antastet – etwa Differenzen zwischen Zeigern in verschiedene Allokationen, weit über das Ende eines Objekts hinaus mitgeführte Offsets oder Arithmetik auf einer NULL-Basis –, schlägt unter Durchsetzung fehl, und genau darum geht es; Apples Referenzdokument sagt über solchen Code, er „wird abstürzen”.³

Welche Geräte setzen es durch?

Laut Release Notes: iPhone-Modelle mit A20 Pro oder neuer, Macs mit M6 oder neuer und Apple-Watch-Modelle mit S11 oder neuer.¹ Auf anderen Geräten wählt der Loader das Slice nicht aus, und es ändert sich nichts.

Ist CPA2 dasselbe wie Arms FEAT_CPA?

Nein. Arms Feature-Registry führt FEAT_CPA als „Instruction-only Checked Pointer Arithmetic” und FEAT_CPA2 als „Checked Pointer Arithmetic”: Das erste liefert die ADDPT-Instruktionsfamilie, die clang ausgibt, das zweite ist die Hardware-Unterstützung für die Prüfung selbst.¹³¹² Apple nennt CPA2 als Voraussetzung, und sein Referenzdokument sagt über A20 Pro und S11: „Beide Chips unterstützen FEAT_CPA2, worauf das arm64e.x1-Slice abzielt.”³

Quellen