arm64e.x1 : la slice d'Apple pour l'arithmétique de pointeurs vérifiée

Qu’est-ce qu’arm64e.x1 ? Une nouvelle slice Mach-O, de sous-type CPU 12, qu’Apple a introduite le 11 septembre en un seul paragraphe dans les notes de version d’iOS 27 RC : elle « introduit des instructions supplémentaires de sécurité matérielle et de performance, dont CPA2 pour une protection MIE renforcée », sur les iPhone dotés d’une puce A20 Pro ou ultérieure, les Mac dotés d’une puce M6 ou ultérieure et les modèles d’Apple Watch dotés d’une puce S11 ou ultérieure.¹ Dans cette slice, Apple clang 21 compile l’arithmétique de pointeurs ordinaire en l’instruction Arm addpt, qui empoisonne un pointeur dont le calcul déborde sur son octet de poids fort, là où réside le tag mémoire, au lieu de laisser ce calcul présenter un tag que le matériel accepterait. Xcode 27 ajoute la slice via un unique réglage de compilation et conditionne son application à l’exécution à l’entitlement Enhanced Security ainsi qu’à deux entitlements qui en dépendent.²³

En bref : Le paragraphe était arrivé dans les notes RC d’iOS et de watchOS 27 au contrôle de 10 h 01 (PT) de mon watcher, et dans celles de macOS à 11 h 12, avec un lien « Learn more » qui pointe vers un hôte de brouillons interne à Apple ; l’article public sur Enhanced Security ne mentionne toujours pas la slice.¹⁴⁵ La RC de Xcode 27, elle, livre déjà tout : la constante de sous-type, un compilateur qui vise apple-a20 avec +cpa, le réglage de compilation et un document de référence qui détaille les quatre interrupteurs.⁶²⁷³ Matériel annoncé : iPhone 18 Pro et iPhone Duo (A20 Pro), le Mac mini M6, l’Apple Watch Series 12 et l’Ultra 4 (S11) ; la famille iPhone 17 n’est pas sur la liste.¹⁹ Compilez les trois slices, gardez l’authentification de pointeurs activée et attendez-vous à des plantages très loin du calcul qui les a provoqués.

Mise à jour du 17 septembre : un blocage de l’envoi vers l’App Store sur macOS 26.6

Apple a ajouté un problème connu à la section Enhanced Security des notes de version de Xcode 27 entre mes récupérations du JSON de documentation du 16 et du 17 septembre : « 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. » (Les apps dont la fonctionnalité Hardware-Checked Pointer Arithmetic Slice est activée ne peuvent pas être envoyées vers l’App Store depuis macOS Tahoe 26.6 avec la signature automatique de Xcode activée.) Le contournement qu’Apple donne : « Distribute with macOS 27 and Xcode 27 or use manual signing. » (Distribuez avec macOS 27 et Xcode 27, ou utilisez la signature manuelle.)¹⁴ Un build qui porte la slice arm64e.x1 a donc un coût de distribution sur l’hôte minimal que Xcode 27 prend en charge : un Mac encore sous Tahoe 26.6, le minimum qu’exige Xcode 27, ne peut pas envoyer ce build avec la signature automatique. La signature manuelle ou un hôte sous macOS 27 lève le blocage, d’après la note d’Apple ; je n’ai pas de machine sous macOS 27 et n’ai essayé ni l’une ni l’autre voie.¹⁴

Ce qui est apparu, et où

Les notes de version d’iOS et d’iPadOS 27 RC se sont enrichies d’une section intitulée Hardware Security, le paragraphe figurant sous son sous-titre New Features. Voici son texte intégral :

arm64e.x1 introduit des instructions supplémentaires de sécurité matérielle et de performance, dont CPA2 pour une protection MIE renforcée. Les appareils prenant en charge arm64e.x1 comprennent les modèles d’iPhone dotés d’une puce A20 Pro ou ultérieure, les ordinateurs Mac dotés d’une puce M6 ou ultérieure et les modèles d’Apple Watch dotés d’une puce S11 ou ultérieure. Dans Xcode, vous pouvez accéder à arm64e.x1 et à CPA2 via le volet enhanced security et un réglage de compilation. Pour en savoir plus, consultez l’article Enhanced Security. (152103975)¹

Les notes de watchOS 27 RC ont reçu le même paragraphe lors du même contrôle. Celles de macOS 27 RC ne l’avaient pas à 10 h 02 (PT), alors même que le paragraphe cite les Mac équipés d’une puce M6 ou ultérieure ; à 11 h 12 (PT), elles le portaient également, avec le même lien.⁴ Mon watcher récupère ces trois pages toutes les quelques minutes ; toutes trois étaient restées inchangées depuis le 9 septembre.

Deux détails de ce paragraphe méritent l’attention. Le lien « Learn more » ne mène pas à la documentation publique. Les données de la page désignent comme cible https://docs.devpubs.apple.com/drafts/f16-dspector-161940504-rapid-isa-adoption-documentation/documentation/xcode/enabling-enhanced-security-for-your-app, un hôte qui ne se résout pas depuis l’extérieur d’Apple.¹ Par ailleurs, l’article public situé au chemin correspondant, Activer enhanced security pour votre app, ne mentionne ni arm64e.x1 ni CPA2 à 10 h 40 (PT) ; il documente toujours les réglages de compilation de cette capacité, de ENABLE_POINTER_AUTHENTICATION à CLANG_ENABLE_STACK_ZERO_INIT.⁵

Les notes de version de Xcode 27 RC portent, sous Enhanced Security, une entrée correspondante depuis la sortie de la RC le 9 septembre, et c’est elle qui nomme le mécanisme :

arm64e.x1, ou slice Hardware-Checked Pointer Arithmetic, met en œuvre l’entitlement Check for Overflow of Pointer Arithmetic en vérifiant les débordements dans les tags mémoire, offrant ainsi une protection supplémentaire par-dessus Memory Integrity Enforcement. (152104701)¹⁰

La slice n’avait rien d’un secret. Le 9 septembre à 13 h 40 (PT), le chercheur qui publie sous le nom de Longhorn écrivait qu’« Apple M6/A20 ship with FEAT_CPA2 - checked pointer arithmetic - and there’s a new executable type for it » et citait une phrase qui s’avère provenir d’un document interne à Xcode.¹¹ Les notes d’iOS et de watchOS ont suivi deux jours plus tard.

La slice, dans le SDK et dans le compilateur

Le SDK iOS de Xcode 27.0 (build 27A266a) définit le sous-type dans 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)

Le commentaire placé au-dessus de la macro utilitaire indique où mène la nomenclature : « Les slices PAC actuelles comprennent ARM64E et ARM64E_X1. Les slices futures peuvent poursuivre cette convention. »⁶

Apple clang 21.0.0 (clang-2100.3.34.2), le compilateur livré dans ce Xcode, accepte -arch arm64e.x1 et le traite comme un processeur différent. Avec -###, il rapporte -target-cpu apple-a20 et une liste de fonctionnalités comprenant +cpa, +mte, +pauth, +pauth-lr et +fpac. Le simple -arch arm64e rapporte -target-cpu apple-a12, sans +cpa.² L’en-tête du fichier objet enregistre le sous-type sous la forme E.X1, et lipo -info nomme l’architecture arm64e.x1.

Toute la différence tient à un mnémonique. Prenons une fonction qui ajoute un indice à un pointeur :

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

Compilé avec -O2 pour arm64e, le corps se résume à un add et un return. Compilé pour arm64e.x1, l’add devient addpt :

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

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

La compilation n’a eu besoin d’aucun flag : choisir l’architecture active l’arithmétique vérifiée.² Le flag existe pour le sens inverse et pour les autres slices. L’aide de clang liste -fchecked-pointer-arithmetic, décrit comme « Enable checked pointer arithmetic, with software sequences if necessary », ainsi que -fno-checked-pointer-arithmetic.² Avec ce flag, arm64e et arm64 ordinaires reçoivent une séquence logicielle : un add ordinaire, un ou exclusif entre la base et le résultat, un test des 10 bits de poids fort, [63:54], face à 0xffc0000000000000 et, s’ils diffèrent, un movk qui écrit 0xc8a2 dans les 16 bits de poids fort du pointeur, ce qui le rend non canonique. Avec -fno-checked-pointer-arithmetic, arm64e.x1 revient à un add ordinaire.²

Ce que CPA2 vérifie

Apple livre à l’intérieur de Xcode 27 un document de référence destiné à son assistant de code, et il explique la vérification mieux que ne le font les notes de version. Sa première phrase : « L’arithmétique de pointeurs vérifiée permet au matériel prenant en charge l’extension FEAT_CPA2 de détecter qu’un calcul de pointeur déborde des bits d’adresse vers les bits de poids fort du pointeur. » Le document explique aussi pourquoi l’octet de poids fort compte : « C’est le débordement vers ces bits qui permet à un calcul de passer d’un objet à un autre tout en présentant encore un tag que le matériel accepte. » Puis : « La détection intervient à deux endroits : l’arithmétique explicite empoisonne son résultat, et chaque load et chaque store vérifient l’addition qu’ils effectuent dans le cadre de leur mode d’adressage. »³

La comparaison porte sur les octets de poids fort. « La vérification compare l’octet de poids fort du résultat, les bits [63:56], à l’octet de poids fort de l’opérande de base. Cet octet porte le tag Memory Tagging Extension (MTE) de 4 bits dans les bits [59:56] lorsque MTE est activé. » Le matériel empoisonne un pointeur qui échoue à la vérification, et c’est cet empoisonnement qu’imite la séquence logicielle ci-dessus : « Un pointeur empoisonné est délibérément non canonique, de sorte que le déréférencement suivant provoque une faute de traduction de niveau 0, remontée sous la forme EXC_ARM_CPA_FAIL (0x108) avec un ESR 0x92000004 (lecture) ou 0x92000044 (écriture). »³

L’instruction vient d’Arm. Le patch LLVM qui en ajoute la prise en charge par l’assembleur, fusionné le 30 novembre 2023, décrit la Checked Pointer Arithmetic Extension, FEAT_CPA, comme annoncée avec l’architecture Armv9.5-A, et ajoute les instructions scalaires ADDPT, SUBPT, MADDPT et MSUBPT ainsi que des formes vectorielles.¹² Les notes d’Apple comme son document de référence parlent de CPA2, l’extension habilitante que le matériel doit prendre en charge, et la définition du document de référence est celle citée plus haut.³

Le « MIE » du paragraphe d’Apple désigne Memory Integrity Enforcement, que l’équipe sécurité d’Apple a annoncé le 9 septembre 2025 comme « notre défense complète pour la sécurité mémoire sur les plateformes Apple », « intégrée directement au matériel et au logiciel Apple dans tous les modèles d’iPhone 17 et d’iPhone Air », par-dessus l’Enhanced Memory Tagging Extension (EMTE) qu’Apple a développée avec Arm.⁸ Ce billet indiquait aux développeurs qu’ils pouvaient « commencer à tester cette protection puissante pour leur app, y compris EMTE sur le matériel qui la prend en charge, à l’aide des réglages Enhanced Security de Xcode ».⁸ CPA2 comble une lacune bien précise du tagging. Le tagging compare le tag contenu dans l’octet de poids fort d’un pointeur avec celui de la mémoire qu’il touche : un pointeur qui se contente de franchir la frontière vers une allocation voisine sans toucher à son octet de poids fort relève donc bien du tagging, les tags diffèrent et l’accès échoue. Le cas que le tagging ne peut pas voir, c’est l’arithmétique qui déborde sur l’octet de poids fort, car elle peut « fabriquer un pointeur dont le tag correspond à une autre allocation » et, selon les termes du document de référence, « sans cette vérification, ce débordement est précisément la manière dont un attaquant mettrait le tagging en échec ».³

Les quatre interrupteurs de Xcode 27

Le document de référence est catégorique : « Quatre choses doivent être activées sur une cible d’app. S’il en manque une, il n’y a aucune protection. »³ Les voici :

1. Le réglage de compilation ENABLE_HARDWARE_CHECKED_POINTER_ARITHMETIC_SLICE = YES, présenté dans Build Settings sous Security comme « Enable Hardware-Checked Pointer Arithmetic Slice ». Il figure dans la spécification du système de compilation de la RC de Xcode 27.³⁷
2. L’entitlement Enhanced Security, com.apple.security.hardened-process, ajouté via la capacité correspondante dans Signing & Capabilities.
3. Le tagging mémoire matériel, com.apple.security.hardened-process.checked-allocations, l’option Memory Safety « Enable Hardware Memory Tagging ».
4. L’entitlement d’application, com.apple.security.hardened-process.checked-allocations.enforce-checked-pointer-arithmetic-overflow, l’option « Enforce Checking for Overflow of Pointer Arithmetic ».

« La ligne 4 est une sous-option de la ligne 3, et la ligne 3 une sous-option de la ligne 2. »³ Le tagging est indispensable parce que l’octet de poids fort doit contenir quelque chose qui vaille la peine d’être comparé.

Le réglage de compilation ne fait qu’une chose : il « ajoute arm64e.x1 à ARCHS_STANDARD ». Ce qui suppose à son tour une condition : « Le réglage reste sans effet si ARCHS est redéfini sur une valeur qui ne repose pas sur ARCHS_STANDARD. » Et un fichier d’entitlements écrit à la main réclame une clé de plus : « La ligne 2 nécessite également com.apple.security.hardened-process.enhanced-security-version-string = 2 ; Xcode écrit cette clé lorsque vous ajoutez la capacité, alors écrivez-la vous-même si vous modifiez directement le fichier d’entitlements. » Le tableau mesuré du document pour une cible iOS est celui qu’il faut retenir.³

Retenez la dernière ligne. Avec la slice activée et l’authentification de pointeurs désactivée, un appareil dépourvu de CPA2 retombe sur arm64 seul et perd l’authentification de pointeurs dont il aurait autrement bénéficié.³ Vérifiez le résultat comme le fait le document :

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

Trois autres faits tirés du même document méritent de figurer à côté du tableau. « __arm64e_x1__ est une macro prédéfinie, destinée au code qui doit être compilé différemment pour la slice arm64e.x1. » Le simulateur, lui, ne demande rien : « Les SDK du simulateur ne définissent aucune architecture arm64e.x1, si bien que le système de compilation la retire des architectures effectives d’une compilation pour simulateur, exactement comme il le fait pour arm64e. » Apple qualifie enfin le surcoût à l’exécution de faible et situe le prix ailleurs, dans la taille : « Le coût, c’est la taille du binaire : une troisième slice. »³ Les bibliothèques et les frameworks ne réclament que le réglage de compilation ; le système accorde les entitlements par processus, à partir de l’exécutable principal. Et une bibliothèque livrée uniquement en arm64e en profite tout de même lorsqu’une app appliquant la vérification la charge : « les instructions load/store de la bibliothèque seront malgré tout vérifiées ».³

Modifications de code : « Généralement aucune. Le compilateur émet les instructions vérifiées dans la slice arm64e.x1, et le matériel les applique dès que les entitlements décrits dans “How to Enable” sont en place. »³ Font exception les motifs dont l’arithmétique touche à l’octet de poids fort, que le document énumère : une différence entre des pointeurs visant deux allocations distinctes, un décalage transporté au-delà de la fin d’un objet, un calcul sur une base NULL et des pointeurs typés comme des entiers dans un calcul. Sa note sur la stabilité tient en une phrase : « le code présentant des bugs latents d’arithmétique de pointeurs plantera ». Le document prévient que l’instruction empoisonnante et le déréférencement fautif « peuvent se trouver dans des fonctions, des fichiers ou des bibliothèques différents ».³ Xcode émet un avertissement à la compilation si l’entitlement d’application est défini sur une cible qui ne compile pas la slice ; le document qualifie cet avertissement de « seul signal indiquant que la configuration est incomplète ».³

Qui possède le matériel

La liste d’Apple parle de puces, et les annonces de septembre les rattachent à des produits. L’A20 Pro équipe l’iPhone 18 Pro et l’iPhone 18 Pro Max, « all powered by A20 Pro », ainsi que l’iPhone Duo, « Powered by the new A20 Pro ».⁹ La S11 est la puce de l’Apple Watch Series 12 et de l’Apple Watch Ultra 4.⁹ Apple a annoncé la M6 le 25 août dans le Mac mini, dans le communiqué intitulé « Apple unveils a more powerful Mac mini featuring the all-new M6 and M5 Pro ».⁹ Annoncé ne veut pas dire disponible : selon le calendrier d’Apple, l’iPhone 18 Pro et les nouvelles montres arrivent en boutique le 18 septembre, le Mac mini le 22 septembre et l’iPhone Duo le 23 octobre.⁹ La liste de plateformes du document de référence ne cite, elle, qu’iOS sur A20 Pro et watchOS sur S11, et ne dit rien du Mac, que les notes de version incluent pourtant.³ Les puces A19 et A19 Pro de l’iPhone 17 et de l’iPhone Air exécutent Memory Integrity Enforcement mais ne figurent pas dans la liste arm64e.x1 : c’est donc la séquence logicielle, et non addpt, que ces téléphones exécuteraient si une compilation activait le flag pour arm64e.¹⁸

Pour quiconque développe pour l’iPhone Duo, cette slice est le premier changement de chaîne d’outils intéressant le Duo qui n’attend pas le SDK d’iOS 27.1. Elle est dans la RC de Xcode 27 dès aujourd’hui, et un Duo, avec son A20 Pro, figure sur la liste d’application dès son premier jour de commercialisation.

Ce que je ferais

Activez la dernière ligne du tableau sur toute app ayant déjà adopté Enhanced Security, et ajoutez d’abord l’entitlement d’application sur une branche. Une fois le matériel entre les mains, traitez chaque EXC_ARM_CPA_FAIL comme un rapport de bug sur l’arithmétique de pointeurs, et cherchez le lieu de l’empoisonnement, pas celui du plantage. Sur arm64e, laissez le flag tranquille : la séquence logicielle coûte des instructions à chaque addition de pointeur, et la slice est le meilleur pari. Tant qu’Apple n’aura pas publié l’article vers lequel pointent ses notes de version, le document de référence contenu dans Xcode reste la description la plus complète qu’elle ait livrée.

Points clés

Pour les ingénieurs iOS et macOS : - arm64e.x1 est le sous-type CPU Mach-O 12 ; clang vise pour lui apple-a20 avec +cpa et compile l’arithmétique de pointeurs en addpt. - L’application exige quatre interrupteurs : le réglage de compilation de la slice, Enhanced Security, le tagging mémoire matériel et l’entitlement de débordement. Compilez arm64 arm64e arm64e.x1.

Pour les responsables sécurité et plateforme : - Sous application, les instructions d’arithmétique vérifiée comparent l’octet de poids fort du résultat à celui de la base et empoisonnent en cas de divergence, ce qui ferme le contournement arithmétique du tagging mémoire ; les calculs d’adresse des load et des store sont eux aussi vérifiés, y compris dans les bibliothèques arm64e ordinaires chargées par une app qui applique la vérification. - Matériel compatible annoncé : A20 Pro (iPhone 18 Pro, iPhone Duo), M6 (Mac mini), S11 (Watch Series 12 et Ultra 4). L’iPhone 17 n’est pas sur la liste ; les appareils arrivent en boutique à partir du 18 septembre.

Pour quiconque suit la documentation d’Apple : - Le paragraphe des notes de version pointe vers un hôte de brouillons interne et l’article public accuse du retard ; la référence fournie avec la RC de Xcode 27 est, pour l’heure, la source complète.

Questions fréquentes

arm64e.x1 remplace-t-il arm64e ?

Non. Le tableau mesuré d’Apple présente arm64 arm64e arm64e.x1 comme la configuration recommandée, et le document de référence précise qu’une cible compilant la slice x1 sans authentification de pointeurs ne livre aucune slice arm64e : les appareils plus anciens perdent donc l’authentification de pointeurs.³

Dois-je modifier mon code ?

En général, non. Le compilateur émet les instructions vérifiées et le matériel les applique dès que les entitlements sont en place. Le code dont l’arithmétique de pointeurs touche à l’octet de poids fort — différences entre des pointeurs visant des allocations distinctes, décalages transportés bien au-delà de la fin d’un objet ou calculs sur une base NULL — échoue sous application, et c’est précisément le but ; le document de référence d’Apple dit d’un tel code qu’il « plantera ».³

Quels appareils l’appliquent ?

Selon les notes de version : les modèles d’iPhone dotés d’une puce A20 Pro ou ultérieure, les Mac dotés d’une puce M6 ou ultérieure et les modèles d’Apple Watch dotés d’une puce S11 ou ultérieure.¹ Sur les autres appareils, le chargeur ne sélectionne pas la slice et rien ne change.

CPA2 est-il la même chose que FEAT_CPA d’Arm ?

Non. Le registre de fonctionnalités d’Arm classe FEAT_CPA comme « Instruction-only Checked Pointer Arithmetic » et FEAT_CPA2 comme « Checked Pointer Arithmetic » : le premier fournit la famille d’instructions ADDPT que clang émet, le second constitue la prise en charge matérielle de la vérification elle-même.¹³¹² Apple désigne CPA2 comme l’exigence, et son document de référence dit de l’A20 Pro et de la S11 que « les deux puces prennent en charge FEAT_CPA2, que vise la slice arm64e.x1 ».³

Sources