arm64e.x1: o slice de aritmética de ponteiros verificada da Apple

O que é o arm64e.x1? Um novo slice do Mach-O, subtipo de CPU 12, que a Apple apresentou em 11 de setembro num único parágrafo das notas de versão do iOS 27 RC: ele “introduz instruções adicionais de segurança de hardware e de desempenho, incluindo o CPA2 para uma proteção MIE mais forte”, em iPhones com A20 Pro ou mais recente, Macs com M6 ou mais recente e modelos de Apple Watch com S11 ou mais recente.¹ Dentro desse slice, o Apple clang 21 compila a aritmética de ponteiros comum para a instrução addpt da Arm, que envenena um ponteiro cuja aritmética transborda para o byte mais alto, onde mora a tag de memória, em vez de deixar o cálculo apresentar uma tag que o hardware aceitaria. O Xcode 27 adiciona o slice com uma única configuração de build e condiciona a aplicação em tempo de execução ao entitlement do Enhanced Security e a dois entitlements abaixo dele.²³

Resumo: O parágrafo já havia chegado às notas do RC do iOS e do watchOS 27 na verificação das 10h01 (PT) do meu watcher, e às do macOS às 11h12, com um link “Learn more” que aponta para um host interno de rascunhos da Apple; o artigo público sobre o Enhanced Security ainda não menciona o slice.¹⁴⁵ O RC do Xcode 27 já entrega tudo: a constante do subtipo, um compilador que mira apple-a20 com +cpa, a configuração de build e um documento de referência que detalha as quatro chaves.⁶²⁷³ Hardware anunciado: iPhone 18 Pro e iPhone Duo (A20 Pro), o Mac mini com M6, Apple Watch Series 12 e Ultra 4 (S11); a família iPhone 17 não está na lista.¹⁹ Compile os três slices, mantenha a autenticação de ponteiros ligada e espere travamentos bem longe da aritmética que os causou.

Atualização, 17 de setembro: um bloqueio de upload para a App Store no macOS 26.6

A Apple acrescentou um problema conhecido à seção Enhanced Security das notas de versão do Xcode 27 entre as minhas buscas do JSON de documentação de 16 e de 17 de setembro: “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 com o recurso Hardware-Checked Pointer Arithmetic Slice ativado não podem ser enviados à App Store no macOS Tahoe 26.6 com a assinatura automática do Xcode ativada). A solução alternativa que a Apple dá: “Distribute with macOS 27 and Xcode 27 or use manual signing.” (distribua com o macOS 27 e o Xcode 27 ou use a assinatura manual).¹⁴ Então um build que carrega o slice arm64e.x1 tem um custo de distribuição no host mínimo que o Xcode 27 suporta: um Mac ainda no Tahoe 26.6, o mínimo que o Xcode 27 exige, não consegue enviar esse build com a assinatura automática. A assinatura manual ou um host com macOS 27 resolvem isso, segundo a nota da Apple; eu não tenho uma máquina com macOS 27 e não testei nenhum dos dois caminhos.¹⁴

O que apareceu, e onde

As notas de versão do iOS e do iPadOS 27 RC ganharam uma seção intitulada Hardware Security, com o parágrafo sob o subtítulo New Features. Seu texto, na íntegra:

O arm64e.x1 introduz instruções adicionais de segurança de hardware e de desempenho, incluindo o CPA2 para uma proteção MIE mais forte. Entre os dispositivos compatíveis com o arm64e.x1 estão modelos de iPhone com chips A20 Pro ou mais recentes, computadores Mac com chips M6 ou mais recentes e modelos de Apple Watch com chips S11 ou mais recentes. Você pode acessar o arm64e.x1 e o CPA2 no Xcode pelo painel enhanced security e por uma configuração de build. Saiba mais no artigo sobre o Enhanced Security. (152103975)¹

As notas do watchOS 27 RC ganharam o mesmo parágrafo na mesma verificação. As do macOS 27 RC ainda não o tinham às 10h02 (PT), embora o parágrafo liste Macs com M6 ou mais recente; às 11h12 (PT) elas também o traziam, com o mesmo link.⁴ Meu watcher busca essas três páginas a cada poucos minutos; todas as três estavam sem alteração desde 9 de setembro.

Dois detalhes desse parágrafo merecem atenção. O link “Learn more” não leva à documentação pública. Os dados da página apontam como destino https://docs.devpubs.apple.com/drafts/f16-dspector-161940504-rapid-isa-adoption-documentation/documentation/xcode/enabling-enhanced-security-for-your-app, um host que não resolve de fora da Apple.¹ E o artigo público no caminho correspondente, Ativar o enhanced security no seu app, não menciona arm64e.x1 nem CPA2 às 10h40 (PT); ele ainda documenta as configurações de build desse recurso, de ENABLE_POINTER_AUTHENTICATION até CLANG_ENABLE_STACK_ZERO_INIT.⁵

As notas de versão do Xcode 27 RC trazem um item correspondente em Enhanced Security desde que o RC saiu, em 9 de setembro, e é ele que nomeia o mecanismo:

O arm64e.x1, ou slice Hardware-Checked Pointer Arithmetic, implementa o entitlement Check for Overflow of Pointer Arithmetic verificando o transbordamento para as tags de memória, o que oferece proteção adicional por cima do Memory Integrity Enforcement. (152104701)¹⁰

O slice não era segredo. Em 9 de setembro, às 13h40 (PT), o pesquisador que publica como Longhorn escreveu que “Apple M6/A20 ship with FEAT_CPA2 - checked pointer arithmetic - and there’s a new executable type for it” e citou uma frase que, como se descobriu, vem de um documento dentro do Xcode.¹¹ As notas do iOS e do watchOS só alcançaram isso dois dias depois.

O slice, no SDK e no compilador

O SDK do iOS no Xcode 27.0 (build 27A266a) define o subtipo em 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)

O comentário acima da macro auxiliar mostra para onde vai a taxonomia: “Os slices PAC atuais incluem ARM64E e ARM64E_X1. Slices futuros podem seguir a convenção.”⁶

O Apple clang 21.0.0 (clang-2100.3.34.2), o compilador desse Xcode, aceita -arch arm64e.x1 e o trata como uma CPU diferente. Com -###, ele informa -target-cpu apple-a20 e uma lista de recursos que inclui +cpa, +mte, +pauth, +pauth-lr e +fpac. O -arch arm64e puro informa -target-cpu apple-a12 e nenhum +cpa.² O cabeçalho do arquivo objeto registra o subtipo como E.X1, e o lipo -info chama a arquitetura de arm64e.x1.

A diferença é um mnemônico. Pegue uma função que soma um índice a um ponteiro:

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

Compilado com -O2 para arm64e, o corpo é um add e um return. Compilado para arm64e.x1, o add vira addpt:

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

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

O build não precisou de nenhuma flag; escolher a arquitetura liga a aritmética verificada.² A flag existe para o sentido contrário e para outros slices. A ajuda do clang lista -fchecked-pointer-arithmetic, descrita como “Enable checked pointer arithmetic, with software sequences if necessary”, e -fno-checked-pointer-arithmetic.² Com a flag, arm64e e arm64 puros ganham uma sequência em software: um add comum, um ou-exclusivo entre base e resultado, um teste dos 10 bits mais altos, [63:54], contra 0xffc0000000000000 e, quando diferem, um movk que escreve 0xc8a2 nos 16 bits mais altos do ponteiro, o que o torna não canônico. Com -fno-checked-pointer-arithmetic, o arm64e.x1 volta a um add comum.²

O que o CPA2 verifica

A Apple inclui dentro do Xcode 27 um documento de referência para seu assistente de código, e ele explica a verificação melhor do que as notas de versão. Sua primeira frase: “A aritmética de ponteiros verificada faz com que o hardware compatível com a extensão FEAT_CPA2 detecte quando um cálculo de ponteiro transborda dos bits de endereço para os bits superiores do ponteiro.” O documento diz por que o byte mais alto importa: “Transbordar para eles é o que permite à aritmética caminhar de um objeto para outro ainda apresentando uma tag que o hardware aceita.” Em seguida: “A detecção acontece em dois lugares: a aritmética explícita envenena seu resultado, e cada load e cada store verificam a soma que realizam como parte do seu modo de endereçamento.”³

A comparação é entre bytes mais altos. “A verificação compara o byte mais alto do resultado, os bits [63:56], com o byte mais alto do operando base. Esse byte carrega a tag de 4 bits da Memory Tagging Extension (MTE) nos bits [59:56] quando a MTE está ativada.” O hardware envenena um ponteiro que não passa na verificação, e é esse envenenamento que a sequência em software acima imita: “Um ponteiro envenenado é deliberadamente não canônico, então a próxima dereferência provoca uma falha de tradução de nível 0, entregue como EXC_ARM_CPA_FAIL (0x108) com ESR 0x92000004 (leitura) ou 0x92000044 (escrita).”³

A instrução vem da Arm. O patch do LLVM que adiciona suporte no assembler, integrado em 30 de novembro de 2023, descreve a Checked Pointer Arithmetic Extension, a FEAT_CPA, como anunciada com a arquitetura Armv9.5-A, e acrescenta as instruções escalares ADDPT, SUBPT, MADDPT e MSUBPT, além de formas vetoriais.¹² Tanto as notas da Apple quanto seu documento de referência falam em CPA2, a extensão habilitadora que o hardware precisa suportar, e a definição do documento de referência é a citada acima.³

O “MIE” do parágrafo da Apple é o Memory Integrity Enforcement, que a equipe de segurança da Apple anunciou em 9 de setembro de 2025 como “nossa defesa abrangente de segurança de memória para as plataformas Apple”, “integrada diretamente ao hardware e ao software da Apple em todos os modelos de iPhone 17 e iPhone Air”, em cima da Enhanced Memory Tagging Extension (EMTE) que a Apple desenvolveu com a Arm.⁸ Aquele post dizia aos desenvolvedores que eles podiam “começar a testar essa proteção poderosa no seu app, incluindo a EMTE em hardware compatível, usando as configurações de Enhanced Security no Xcode”.⁸ O CPA2 fecha uma lacuna específica do tagging. O tagging compara a tag no byte mais alto de um ponteiro com a tag da memória que ele toca, então um ponteiro que apenas cruza para uma alocação vizinha sem mexer no seu byte mais alto é justamente o caso do tagging: as tags diferem e o acesso falha. A aritmética que transborda para o byte mais alto é o caso que o tagging não enxerga, porque ela consegue “fabricar um ponteiro cuja tag corresponde a outra alocação” e, nas palavras do documento de referência, “sem essa verificação, esse transbordamento é como um atacante derrotaria o tagging”.³

As quatro chaves do Xcode 27

O documento de referência é direto: “Quatro coisas precisam estar ativadas em um target de app. Se faltar uma, não há proteção.”³ São elas:

1. A configuração de build ENABLE_HARDWARE_CHECKED_POINTER_ARITHMETIC_SLICE = YES, exibida em Build Settings sob Security como “Enable Hardware-Checked Pointer Arithmetic Slice”. Ela existe na especificação do sistema de build do RC do Xcode 27.³⁷
2. O entitlement do Enhanced Security, com.apple.security.hardened-process, adicionado pela capability em Signing & Capabilities.
3. O tagging de memória por hardware, com.apple.security.hardened-process.checked-allocations, a opção de Memory Safety “Enable Hardware Memory Tagging”.
4. O entitlement de aplicação, com.apple.security.hardened-process.checked-allocations.enforce-checked-pointer-arithmetic-overflow, a opção “Enforce Checking for Overflow of Pointer Arithmetic”.

“A linha 4 é uma subopção da linha 3, e a linha 3, da linha 2.”³ O tagging é obrigatório porque o byte mais alto precisa guardar algo que valha a pena comparar.

A configuração de build faz uma coisa só: ela “acrescenta arm64e.x1 ao ARCHS_STANDARD”. Isso tem um pré-requisito próprio: “A configuração não tem efeito se ARCHS for sobrescrito por algo que não seja baseado em ARCHS_STANDARD.” E um arquivo de entitlements escrito à mão precisa de mais uma chave: “A linha 2 também precisa de com.apple.security.hardened-process.enhanced-security-version-string = 2; o Xcode escreve essa chave quando você adiciona a capability, então escreva você mesmo se editar o arquivo de entitlements diretamente.” A tabela medida do documento para um target de iOS é a que vale memorizar.³

Use a última linha. Com o slice ligado e a autenticação de ponteiros desligada, um dispositivo sem CPA2 cai para arm64 puro e perde a autenticação de ponteiros que teria de outro modo.³ Verifique o resultado do jeito que o documento faz:

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

Mais três fatos do mesmo documento merecem ficar ao lado da tabela. “__arm64e_x1__ é uma macro predefinida, para código que precisa ser compilado de forma diferente para o slice arm64e.x1.” O simulador não precisa de nada: “Os SDKs do simulador não definem nenhuma arquitetura arm64e.x1, então o sistema de build a remove das arquiteturas efetivas de um build para simulador exatamente como faz com arm64e.” E a Apple descreve o custo em tempo de execução como baixo e o preço como tamanho: “O custo é o tamanho do binário: um terceiro slice.”³ Bibliotecas e frameworks precisam apenas da configuração de build; o sistema concede entitlements por processo, a partir do executável principal. E uma biblioteca que traz só arm64e ainda se beneficia quando um app com aplicação ativada a carrega: “as instruções load/store da biblioteca continuarão sendo verificadas”.³

Mudanças de código: “Em geral, nenhuma. O compilador emite as instruções verificadas no slice arm64e.x1, e o hardware as aplica assim que os entitlements de ‘How to Enable’ estiverem no lugar.”³ As exceções são os padrões cuja aritmética mexe no byte mais alto, que o documento lista: uma diferença entre ponteiros para duas alocações, um deslocamento levado para além do fim de um objeto, aritmética sobre uma base NULL e ponteiros com tipo inteiro em cálculos. Sua nota sobre estabilidade é uma frase só: “código com bugs latentes de aritmética de ponteiros vai travar”. O documento avisa que a instrução que envenena e a dereferência que falha “podem estar em funções, arquivos ou bibliotecas diferentes”.³ O Xcode avisa na hora do build se o entitlement de aplicação estiver definido em um target que não compila o slice; o documento chama esse aviso de “o único sinal de que a configuração está incompleta”.³

Quem tem o hardware

A lista da Apple é de chips, e os lançamentos de setembro os mapeiam para produtos. O A20 Pro está no iPhone 18 Pro e no iPhone 18 Pro Max, “all powered by A20 Pro”, e no iPhone Duo, “Powered by the new A20 Pro”.⁹ O S11 é o chip do Apple Watch Series 12 e do Apple Watch Ultra 4.⁹ A Apple anunciou o M6 em 25 de agosto no Mac mini, no comunicado intitulado “Apple unveils a more powerful Mac mini featuring the all-new M6 and M5 Pro”.⁹ Anunciado não é o mesmo que na mão: pelas datas da Apple, o iPhone 18 Pro e os novos relógios chegam às lojas em 18 de setembro, o Mac mini em 22 de setembro e o iPhone Duo em 23 de outubro.⁹ A própria lista de plataformas do documento de referência cita iOS no A20 Pro e watchOS no S11 e não diz nada sobre o Mac, que as notas de versão incluem.³ Os chips A19 e A19 Pro do iPhone 17 e do iPhone Air rodam o Memory Integrity Enforcement, mas não estão na lista do arm64e.x1, então o que esses aparelhos rodariam, se um build ligasse a flag para arm64e, seria a sequência em software, não o addpt.¹⁸ Para Macs, O Xcode 27 abandona a Intel cobre a outra mudança de ARCHS_STANDARD da versão, que remove o x86_64 com deployment target 27.0.

Para quem desenvolve para o iPhone Duo, o slice é a primeira mudança de toolchain relevante para o Duo que não espera o SDK do iOS 27.1. Ele está no RC do Xcode 27 hoje, e um Duo, com seu A20 Pro, entra na lista de aplicação desde o primeiro dia em que chegar às lojas. Prepare seu app para o iPhone Duo acompanha um app real por todas as posições e pelo envio à App Store.

O que eu faria

Ligue a última linha da tabela em qualquer app que já adote o Enhanced Security, e adicione o entitlement de aplicação primeiro em um branch. Quando o hardware chegar, trate cada EXC_ARM_CPA_FAIL como um relatório de bug sobre aritmética de ponteiros, e procure o ponto do envenenamento, não o do travamento. No arm64e, deixe a flag quieta: a sequência em software custa instruções em cada soma de ponteiro, e o slice é a melhor aposta. Até a Apple publicar o artigo para o qual suas notas de versão apontam, o documento de referência dentro do Xcode é a descrição mais completa que ela entregou.

Principais conclusões

Para quem trabalha com iOS e macOS: - O arm64e.x1 é o subtipo de CPU 12 do Mach-O; o clang mira apple-a20 com +cpa para ele e compila a aritmética de ponteiros para addpt. - A aplicação exige quatro chaves: a configuração de build do slice, o Enhanced Security, o tagging de memória por hardware e o entitlement de transbordamento. Compile arm64 arm64e arm64e.x1.

Para lideranças de segurança e de plataforma: - Sob aplicação, as instruções de aritmética verificada comparam o byte mais alto do resultado com o da base e envenenam quando não batem, fechando o desvio aritmético contra o tagging de memória; os cálculos de endereço de load e store também recebem verificações, inclusive em bibliotecas arm64e comuns carregadas por um app com aplicação ativada. - Hardware compatível anunciado: A20 Pro (iPhone 18 Pro, iPhone Duo), M6 (Mac mini), S11 (Watch Series 12 e Ultra 4). O iPhone 17 não está na lista; os dispositivos chegam às lojas a partir de 18 de setembro.

Para quem acompanha a documentação da Apple: - O parágrafo das notas de versão aponta para um host interno de rascunhos e o artigo público está atrasado; a referência que vem junto com o RC do Xcode 27 é, por ora, a fonte completa.

Perguntas frequentes

O arm64e.x1 substitui o arm64e?

Não. A própria tabela medida da Apple mostra arm64 arm64e arm64e.x1 como a configuração recomendada, e o documento de referência diz que um target que compila o slice x1 sem autenticação de ponteiros não entrega slice arm64e nenhum, de modo que dispositivos mais antigos perdem a autenticação de ponteiros.³

Preciso mudar o código?

Normalmente não. O compilador emite as instruções verificadas e o hardware as aplica assim que os entitlements estão no lugar. Código cuja aritmética de ponteiros mexe no byte mais alto de um ponteiro — diferenças entre ponteiros para alocações distintas, deslocamentos levados bem além do fim de um objeto ou aritmética sobre uma base NULL — falha sob aplicação, e é esse justamente o objetivo; o documento de referência da Apple diz que esse código “vai travar”.³

Quais dispositivos aplicam isso?

Segundo as notas de versão: modelos de iPhone com A20 Pro ou mais recente, Macs com M6 ou mais recente e modelos de Apple Watch com S11 ou mais recente.¹ Nos demais dispositivos o loader não seleciona o slice, e nada muda.

O CPA2 é a mesma coisa que a FEAT_CPA da Arm?

Não. O registro de recursos da Arm lista a FEAT_CPA como “Instruction-only Checked Pointer Arithmetic” e a FEAT_CPA2 como “Checked Pointer Arithmetic”: a primeira fornece a família de instruções ADDPT que o clang emite, e a segunda é o suporte de hardware para a verificação em si.¹³¹² A Apple aponta o CPA2 como o requisito, e seu documento de referência diz sobre o A20 Pro e o S11 que “Os dois chips suportam FEAT_CPA2, que é o alvo do slice arm64e.x1”.³

Fontes