arm64e.x1: el slice de aritmética de punteros verificada de Apple

¿Qué es arm64e.x1? Un nuevo slice de Mach-O, subtipo de CPU 12, que Apple presentó el 11 de septiembre en un solo párrafo de las notas de la versión RC de iOS 27: “introduce instrucciones adicionales de seguridad de hardware y de rendimiento, entre ellas CPA2 para una protección MIE más fuerte”, en iPhone con A20 Pro o posterior, Mac con M6 o posterior y modelos de Apple Watch con S11 o posterior.¹ Dentro de ese slice, Apple clang 21 compila la aritmética de punteros corriente a la instrucción addpt de Arm, que envenena un puntero cuya aritmética se desborda hacia su byte más alto, donde vive la etiqueta de memoria, en lugar de dejar que el cálculo presente una etiqueta que el hardware aceptaría. Xcode 27 agrega el slice con un único ajuste de compilación y condiciona la aplicación en tiempo de ejecución al entitlement de Enhanced Security y a dos entitlements que dependen de él.²³

En resumen: El párrafo ya había llegado a las notas RC de iOS y watchOS 27 en la comprobación de las 10:01 a. m. (PT) de mi watcher, y a las de macOS a las 11:12 a. m., con un enlace “Learn more” que apunta a un host interno de borradores de Apple; el artículo público sobre Enhanced Security todavía no menciona el slice.¹⁴⁵ El RC de Xcode 27 ya trae todo: la constante del subtipo, un compilador que apunta a apple-a20 con +cpa, el ajuste de compilación y un documento de referencia que detalla los cuatro interruptores.⁶²⁷³ Hardware anunciado: iPhone 18 Pro e iPhone Duo (A20 Pro), la Mac mini con M6, Apple Watch Series 12 y Ultra 4 (S11); la familia iPhone 17 no está en la lista.¹⁹ Compila los tres slices, deja activada la autenticación de punteros y prepárate para fallos muy lejos de la aritmética que los provocó.

Actualización del 17 de septiembre: un bloqueo de subidas al App Store en macOS 26.6

Apple agregó un problema conocido a la sección Enhanced Security de las notas de la versión de Xcode 27 entre mis descargas del JSON de documentación del 16 y del 17 de septiembre: “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.” (las apps con la función Hardware-Checked Pointer Arithmetic Slice activada no se pueden subir al App Store desde macOS Tahoe 26.6 con la firma automática de Xcode activada). La solución alternativa que da Apple: “Distribute with macOS 27 and Xcode 27 or use manual signing.” (distribuye con macOS 27 y Xcode 27, o usa la firma manual).¹⁴ Así que una compilación que lleva el slice arm64e.x1 tiene un costo de distribución en el host mínimo que admite Xcode 27: una Mac que sigue en Tahoe 26.6, el mínimo que Xcode 27 exige, no puede subir esa compilación con firma automática. La firma manual o un host con macOS 27 lo resuelven, según la nota de Apple; no tengo ninguna máquina con macOS 27 y no he probado ninguna de las dos vías.¹⁴

Qué apareció, y dónde

Las notas de la versión RC de iOS e iPadOS 27 sumaron una sección titulada Hardware Security, con el párrafo bajo su subtítulo New Features. Su texto, completo:

arm64e.x1 introduce instrucciones adicionales de seguridad de hardware y de rendimiento, entre ellas CPA2 para una protección MIE más fuerte. Entre los dispositivos compatibles con arm64e.x1 se cuentan los modelos de iPhone con chips A20 Pro o posteriores, las computadoras Mac con chips M6 o posteriores y los modelos de Apple Watch con chips S11 o posteriores. Puedes acceder a arm64e.x1 y a CPA2 en Xcode mediante el panel de enhanced security y un ajuste de compilación. Más información en el artículo sobre Enhanced Security. (152103975)¹

Las notas del RC de watchOS 27 sumaron el mismo párrafo en la misma comprobación. Las del RC de macOS no lo tenían a las 10:02 a. m. (PT), aunque el párrafo enumera las Mac con M6 o posterior; a las 11:12 a. m. (PT) también lo llevaban, con el mismo enlace.⁴ Mi watcher descarga esas tres páginas cada pocos minutos; las tres llevaban sin cambios desde el 9 de septiembre.

Dos detalles de ese párrafo merecen atención. El enlace “Learn more” no lleva a la documentación pública. Los datos de la página señalan como destino https://docs.devpubs.apple.com/drafts/f16-dspector-161940504-rapid-isa-adoption-documentation/documentation/xcode/enabling-enhanced-security-for-your-app, un host que no se resuelve desde fuera de Apple.¹ Y el artículo público en la ruta equivalente, Activar enhanced security en tu app, no menciona arm64e.x1 ni CPA2 a las 10:40 a. m. (PT); sigue documentando los ajustes de compilación de esa capacidad, desde ENABLE_POINTER_AUTHENTICATION hasta CLANG_ENABLE_STACK_ZERO_INIT.⁵

Las notas de la versión RC de Xcode 27 llevan una entrada equivalente bajo Enhanced Security desde que el RC salió el 9 de septiembre, y es esa la que nombra el mecanismo:

arm64e.x1, o el slice Hardware-Checked Pointer Arithmetic, implementa el entitlement Check for Overflow of Pointer Arithmetic comprobando el desbordamiento hacia las etiquetas de memoria, con lo que ofrece protección adicional por encima de Memory Integrity Enforcement. (152104701)¹⁰

El slice no era ningún secreto. El 9 de septiembre a la 1:40 p. m. (PT), el investigador que publica como Longhorn escribió que “Apple M6/A20 ship with FEAT_CPA2 - checked pointer arithmetic - and there’s a new executable type for it” y citó una frase que resulta provenir de un documento que viene dentro de Xcode.¹¹ Las notas de iOS y watchOS se pusieron al día dos días después.

El slice, en el SDK y en el compilador

El SDK de iOS en Xcode 27.0 (build 27A266a) define el subtipo en 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)

El comentario que hay sobre la macro auxiliar indica hacia dónde va la taxonomía: “Los slices PAC actuales incluyen ARM64E y ARM64E_X1. Los slices futuros pueden seguir la convención.”⁶

Apple clang 21.0.0 (clang-2100.3.34.2), el compilador de ese Xcode, acepta -arch arm64e.x1 y lo trata como una CPU distinta. Con -### informa -target-cpu apple-a20 y una lista de características que incluye +cpa, +mte, +pauth, +pauth-lr y +fpac. El -arch arm64e a secas informa -target-cpu apple-a12 y ningún +cpa.² El encabezado del archivo objeto registra el subtipo como E.X1, y lipo -info llama a la arquitectura arm64e.x1.

La diferencia es un solo mnemónico. Toma una función que suma un índice a un puntero:

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

Compilado con -O2 para arm64e, el cuerpo es un add y un return. Compilado para arm64e.x1, el add se convierte en addpt:

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

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

La compilación no necesitó ninguna bandera; elegir la arquitectura activa la aritmética verificada.² La bandera existe para el sentido contrario y para otros slices. La ayuda de clang lista -fchecked-pointer-arithmetic, descrita como “Enable checked pointer arithmetic, with software sequences if necessary”, y -fno-checked-pointer-arithmetic.² Con la bandera, arm64e y arm64 a secas reciben una secuencia por software: un add corriente, un o exclusivo entre base y resultado, una prueba de los 10 bits más altos, [63:54], contra 0xffc0000000000000 y, cuando difieren, un movk que escribe 0xc8a2 en los 16 bits más altos del puntero, lo que lo vuelve no canónico. Con -fno-checked-pointer-arithmetic, arm64e.x1 vuelve a un add corriente.²

Qué comprueba CPA2

Apple incluye dentro de Xcode 27 un documento de referencia para su asistente de código, y ahí la comprobación queda mejor explicada que en las notas de la versión. Su primera frase: “La aritmética de punteros verificada hace que el hardware compatible con la extensión FEAT_CPA2 detecte cuándo el cálculo de un puntero se desborda desde los bits de dirección hacia los bits superiores del puntero.” El documento explica por qué importa el byte más alto: “Desbordarse hacia ellos es lo que permite que la aritmética camine de un objeto a otro sin dejar de presentar una etiqueta que el hardware acepta.” Y luego: “La detección ocurre en dos lugares: la aritmética explícita envenena su resultado, y cada load y cada store comprueban la suma que realizan como parte de su modo de direccionamiento.”³

La comparación es entre bytes altos. “La comprobación compara el byte más alto del resultado, los bits [63:56], con el byte más alto del operando base. Ese byte lleva la etiqueta de 4 bits de Memory Tagging Extension (MTE) en los bits [59:56] cuando MTE está activado.” El hardware envenena un puntero que no supera la comprobación, y ese envenenamiento es lo que imita la secuencia por software anterior: “Un puntero envenenado es deliberadamente no canónico, así que la siguiente desreferencia provoca un fallo de traducción de nivel 0, entregado como EXC_ARM_CPA_FAIL (0x108) con ESR 0x92000004 (lectura) o 0x92000044 (escritura).”³

La instrucción viene de Arm. El parche de LLVM que añade soporte en el ensamblador, fusionado el 30 de noviembre de 2023, describe la Checked Pointer Arithmetic Extension, FEAT_CPA, como anunciada con la arquitectura Armv9.5-A, y agrega las instrucciones escalares ADDPT, SUBPT, MADDPT y MSUBPT más formas vectoriales.¹² Tanto las notas de Apple como su documento de referencia hablan de CPA2, la extensión habilitadora que el hardware debe admitir, y la definición del documento de referencia es la citada arriba.³

El “MIE” del párrafo de Apple es Memory Integrity Enforcement, que el equipo de seguridad de Apple anunció el 9 de septiembre de 2025 como “nuestra defensa integral de seguridad de memoria para las plataformas de Apple”, “integrada directamente en el hardware y el software de Apple en todos los modelos de iPhone 17 y iPhone Air”, sobre la Enhanced Memory Tagging Extension (EMTE) que Apple desarrolló junto con Arm.⁸ Aquella publicación les decía a los desarrolladores que podían “empezar a probar esta potente protección para su app, incluido EMTE en el hardware que lo admite, usando los ajustes de Enhanced Security en Xcode”.⁸ CPA2 cierra un hueco concreto del etiquetado. El etiquetado compara la etiqueta del byte más alto de un puntero con la de la memoria que toca, así que un puntero que simplemente cruza hacia una asignación vecina sin alterar su byte más alto es el caso que el etiquetado sí ve: las etiquetas difieren y el acceso falla. La aritmética que se desborda hacia el byte más alto es el caso que el etiquetado no puede ver, porque puede “fabricar un puntero cuya etiqueta coincida con otra asignación” y, en palabras del documento de referencia, “sin esta comprobación, ese desbordamiento es la vía por la que un atacante derrotaría el etiquetado”.³

Los cuatro interruptores de Xcode 27

El documento de referencia es tajante: “Hay que activar cuatro cosas en el target de una app. Si falta una, no hay protección.”³ Son estas:

1. El ajuste de compilación ENABLE_HARDWARE_CHECKED_POINTER_ARITHMETIC_SLICE = YES, que aparece en Build Settings bajo Security como “Enable Hardware-Checked Pointer Arithmetic Slice”. Existe en la especificación del sistema de compilación del RC de Xcode 27.³⁷
2. El entitlement de Enhanced Security, com.apple.security.hardened-process, que se agrega mediante la capacidad correspondiente en Signing & Capabilities.
3. El etiquetado de memoria por hardware, com.apple.security.hardened-process.checked-allocations, la opción de Memory Safety “Enable Hardware Memory Tagging”.
4. El entitlement de aplicación, com.apple.security.hardened-process.checked-allocations.enforce-checked-pointer-arithmetic-overflow, la opción “Enforce Checking for Overflow of Pointer Arithmetic”.

“La fila 4 es una subopción de la fila 3, y la fila 3 de la fila 2.”³ El etiquetado hace falta porque el byte más alto tiene que guardar algo que valga la pena comparar.

El ajuste de compilación hace una sola cosa: “añade arm64e.x1 a ARCHS_STANDARD”. Eso tiene a su vez un requisito previo: “El ajuste no surte efecto si ARCHS se sobrescribe con algo que no esté basado en ARCHS_STANDARD.” Y un archivo de entitlements escrito a mano necesita una clave más: “La fila 2 también necesita com.apple.security.hardened-process.enhanced-security-version-string = 2; Xcode escribe esa clave cuando agregas la capacidad, así que escríbela tú mismo si editas el archivo de entitlements directamente.” La tabla medida del documento para un target de iOS es la que conviene memorizar.³

Usa la última fila. Con el slice activado y la autenticación de punteros desactivada, un dispositivo sin CPA2 retrocede a arm64 a secas y pierde la autenticación de punteros que habría tenido de otro modo.³ Verifica el resultado como lo hace el documento:

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

Tres datos más del mismo documento van junto a la tabla. “__arm64e_x1__ es una macro predefinida, para código que deba compilarse de forma distinta para el slice arm64e.x1.” El simulador no necesita nada: “Los SDK del simulador no definen ninguna arquitectura arm64e.x1, así que el sistema de compilación la descarta de las arquitecturas efectivas de una compilación para simulador igual que hace con arm64e.” Y Apple describe la sobrecarga en tiempo de ejecución como baja y el costo como tamaño: “El costo es el tamaño del binario: un tercer slice.”³ Las bibliotecas y los frameworks solo requieren el ajuste de compilación; el sistema concede los entitlements por proceso, a partir del ejecutable principal. Y una biblioteca que solo trae arm64e se beneficia igualmente cuando la carga una app que aplica la comprobación: “las instrucciones load/store de la biblioteca se seguirán comprobando”.³

Cambios de código: “Por lo general, ninguno. El compilador emite las instrucciones verificadas en el slice arm64e.x1, y el hardware las aplica una vez que los entitlements de ‘How to Enable’ están en su sitio.”³ Las excepciones son los patrones cuya aritmética altera el byte más alto, que el documento enumera: la diferencia entre punteros a dos asignaciones distintas, un desplazamiento arrastrado más allá del final de un objeto, la aritmética sobre una base NULL y los punteros con tipo entero dentro de un cálculo. Su nota sobre estabilidad es una sola frase: “el código con errores latentes de aritmética de punteros fallará”. El documento advierte de que la instrucción que envenena y la desreferencia que falla “pueden estar en funciones, archivos o bibliotecas distintos”.³ Xcode avisa en tiempo de compilación si el entitlement de aplicación está puesto en un target que no compila el slice; el documento llama a ese aviso “la única señal de que la configuración está incompleta”.³

Quién tiene el hardware

La lista de Apple son chips, y los lanzamientos de septiembre los asignan a productos. El A20 Pro está en el iPhone 18 Pro y el iPhone 18 Pro Max, “all powered by A20 Pro”, y en el iPhone Duo, “Powered by the new A20 Pro”.⁹ El S11 es el chip del Apple Watch Series 12 y del Apple Watch Ultra 4.⁹ Apple anunció el M6 el 25 de agosto en la Mac mini, en el comunicado titulado “Apple unveils a more powerful Mac mini featuring the all-new M6 and M5 Pro”.⁹ Anunciado no es lo mismo que tenerlo en la mano: según las fechas de Apple, el iPhone 18 Pro y los nuevos relojes llegan a las tiendas el 18 de septiembre, la Mac mini el 22 de septiembre y el iPhone Duo el 23 de octubre.⁹ La propia lista de plataformas del documento de referencia nombra iOS en A20 Pro y watchOS en S11, y no dice nada de la Mac, que las notas de la versión sí incluyen.³ Los chips A19 y A19 Pro del iPhone 17 y el iPhone Air ejecutan Memory Integrity Enforcement pero no están en la lista de arm64e.x1, así que lo que correrían esos teléfonos si una compilación activara la bandera para arm64e sería la secuencia por software, no addpt.¹⁸ Para la Mac, Xcode 27 abandona Intel cubre el otro cambio de ARCHS_STANDARD de esta versión: la eliminación de x86_64 con un deployment target de 27.0.

Para quien desarrolle para el iPhone Duo, el slice es el primer cambio de cadena de herramientas relevante para el Duo que no espera al SDK de iOS 27.1. Está hoy mismo en el RC de Xcode 27, y un Duo, con su A20 Pro, entra en la lista de aplicación desde el primer día que se venda. Prepara tu app para el iPhone Duo lleva una app real por cada postura y por el envío a revisión.

Qué haría yo

Activa la última fila de la tabla en cualquier app que ya haya adoptado Enhanced Security, y agrega primero el entitlement de aplicación en una rama. Cuando llegue el hardware, trata cada EXC_ARM_CPA_FAIL como un informe de error sobre aritmética de punteros, y busca el punto donde se envenena, no donde se produce el fallo. En arm64e, deja la bandera en paz: la secuencia por software cuesta instrucciones en cada suma de punteros, y el slice es la mejor apuesta. Hasta que Apple publique el artículo al que enlazan sus notas de la versión, el documento de referencia que viene dentro de Xcode es la descripción más completa que ha entregado.

Conclusiones clave

Para ingenieros de iOS y macOS: - arm64e.x1 es el subtipo de CPU 12 de Mach-O; clang apunta para él a apple-a20 con +cpa y compila la aritmética de punteros a addpt. - La aplicación necesita cuatro interruptores: el ajuste de compilación del slice, Enhanced Security, el etiquetado de memoria por hardware y el entitlement de desbordamiento. Compila arm64 arm64e arm64e.x1.

Para responsables de seguridad y de plataforma: - Bajo aplicación, las instrucciones de aritmética verificada comparan el byte más alto del resultado con el de la base y envenenan cuando no coinciden, con lo que cierran el rodeo aritmético contra el etiquetado de memoria; los cálculos de dirección de load y store también reciben comprobaciones, incluso en bibliotecas arm64e corrientes cargadas por una app que aplica la comprobación. - Hardware compatible anunciado: A20 Pro (iPhone 18 Pro, iPhone Duo), M6 (Mac mini), S11 (Watch Series 12 y Ultra 4). El iPhone 17 no está en la lista; los dispositivos llegan a las tiendas a partir del 18 de septiembre.

Para quien siga la documentación de Apple: - El párrafo de las notas de la versión enlaza a un host interno de borradores y el artículo público va por detrás; la referencia incluida en el RC de Xcode 27 es, por ahora, la fuente completa.

Preguntas frecuentes

¿arm64e.x1 reemplaza a arm64e?

No. La propia tabla medida de Apple presenta arm64 arm64e arm64e.x1 como la configuración recomendada, y el documento de referencia dice que un target que compile el slice x1 sin autenticación de punteros no entrega ningún slice arm64e, de modo que los dispositivos más antiguos pierden la autenticación de punteros.³

¿Tengo que cambiar código?

Normalmente no. El compilador emite las instrucciones verificadas y el hardware las aplica en cuanto los entitlements están en su sitio. El código cuya aritmética de punteros altera el byte más alto de un puntero —diferencias entre punteros a asignaciones distintas, desplazamientos arrastrados mucho más allá del final de un objeto o aritmética sobre una base NULL— falla bajo aplicación, que es justamente el objetivo; el documento de referencia de Apple dice de ese código que “fallará”.³

¿Qué dispositivos lo aplican?

Según las notas de la versión: los modelos de iPhone con A20 Pro o posterior, las Mac con M6 o posterior y los modelos de Apple Watch con S11 o posterior.¹ En los demás dispositivos el cargador no selecciona el slice y nada cambia.

¿CPA2 es lo mismo que FEAT_CPA de Arm?

No. El registro de características de Arm lista FEAT_CPA como “Instruction-only Checked Pointer Arithmetic” y FEAT_CPA2 como “Checked Pointer Arithmetic”: la primera aporta la familia de instrucciones ADDPT que clang emite, y la segunda es el soporte de hardware para la comprobación en sí.¹³¹² Apple nombra CPA2 como el requisito, y su documento de referencia dice del A20 Pro y el S11 que “Ambos chips admiten FEAT_CPA2, al que apunta el slice arm64e.x1”.³

Fuentes