arm64e.x1: wycinek Apple ze sprawdzaną arytmetyką wskaźników

Czym jest arm64e.x1? To nowy wycinek (slice) Mach-O o podtypie CPU 12, który Apple wprowadziło 11 września jednym akapitem w informacjach o wydaniu iOS 27 RC: „wprowadza dodatkowe sprzętowe instrukcje bezpieczeństwa i wydajności, w tym CPA2 zapewniające silniejszą ochronę MIE”, w iPhone’ach z układem A20 Pro lub nowszym, komputerach Mac z układem M6 lub nowszym oraz modelach Apple Watch z układem S11 lub nowszym.¹ W tym wycinku Apple clang 21 kompiluje zwykłą arytmetykę wskaźników do instrukcji Arm addpt, która zatruwa wskaźnik, gdy jego arytmetyka przepełni się do najstarszego bajtu, czyli tam, gdzie mieszka znacznik pamięci, zamiast pozwolić, by obliczenie przedstawiło znacznik akceptowany przez sprzęt. Xcode 27 dodaje ten wycinek jednym ustawieniem kompilacji, a egzekwowanie w czasie wykonania uzależnia od uprawnienia Enhanced Security oraz dwóch uprawnień leżących poniżej.²³

W skrócie: Do sprawdzenia o 10:01 czasu PT przez mój watcher akapit trafił już do informacji o wydaniu RC dla iOS i watchOS 27, a do informacji dla macOS o 11:12 — wraz z odnośnikiem „Learn more” prowadzącym do wewnętrznego hosta roboczego Apple; publiczny artykuł o Enhanced Security nadal nie wspomina o tym wycinku.¹⁴⁵ Xcode 27 RC dostarcza już wszystko: stałą podtypu, kompilator celujący w apple-a20 z +cpa, ustawienie kompilacji oraz dokument referencyjny, który rozpisuje cztery przełączniki.⁶²⁷³ Ogłoszony sprzęt: iPhone 18 Pro i iPhone Duo (A20 Pro), Mac mini z M6, Apple Watch Series 12 i Ultra 4 (S11); rodzina iPhone 17 nie znalazła się na liście.¹⁹ Warto zbudować wszystkie trzy wycinki, pozostawić włączone uwierzytelnianie wskaźników i liczyć się z awariami dalekimi od arytmetyki, która je wywołała.

Aktualizacja, 17 września: blokada przesyłania do App Store na macOS 26.6

Apple dodało znany problem do sekcji Enhanced Security w informacjach o wydaniu Xcode 27 między moimi pobraniami JSON dokumentacji z 16 i 17 września: „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.” (aplikacji z włączoną funkcją Hardware-Checked Pointer Arithmetic Slice nie da się przesłać do App Store na macOS Tahoe 26.6 przy włączonym automatycznym podpisywaniu w Xcode). Obejście, które podaje Apple: „Distribute with macOS 27 and Xcode 27 or use manual signing.” (dystrybuować z macOS 27 i Xcode 27 albo użyć podpisywania ręcznego).¹⁴ Kompilacja, która niesie wycinek arm64e.x1, ma więc koszt dystrybucyjny na najniższym hoście, jaki Xcode 27 obsługuje: Mac wciąż na Tahoe 26.6, czyli na minimum, którego Xcode 27 wymaga, nie prześle takiej kompilacji z automatycznym podpisywaniem. Według noty Apple rozwiązuje to podpisywanie ręczne albo host z macOS 27; nie mam maszyny z macOS 27 i nie próbowałem żadnej z tych dróg.¹⁴

Co się pojawiło i gdzie

W informacjach o wydaniu iOS i iPadOS 27 RC przybyła sekcja zatytułowana Hardware Security, a wspomniany akapit umieszczono pod jej podtytułem New Features. Oto jego pełna treść:

arm64e.x1 wprowadza dodatkowe sprzętowe instrukcje bezpieczeństwa i wydajności, w tym CPA2 zapewniające silniejszą ochronę MIE. Do urządzeń obsługujących arm64e.x1 należą modele iPhone’a z układami A20 Pro lub nowszymi, komputery Mac z układami M6 lub nowszymi oraz modele Apple Watch z układami S11 lub nowszymi. Dostęp do arm64e.x1 i CPA2 w Xcode można uzyskać przez panel enhanced security oraz ustawienie kompilacji. Więcej informacji znajduje się w artykule o Enhanced Security. (152103975)¹

Informacje o wydaniu watchOS 27 RC otrzymały ten sam akapit przy tym samym sprawdzeniu. Informacje dla macOS 27 RC jeszcze go nie miały o 10:02 czasu PT, choć akapit wymienia komputery Mac z układem M6 lub nowszym; o 11:12 czasu PT również go zawierały, z tym samym odnośnikiem.⁴ Mój watcher pobiera te trzy strony co kilka minut; wszystkie trzy pozostawały niezmienione od 9 września.

Dwa szczegóły tego akapitu zasługują na uwagę. Odnośnik „Learn more” nie prowadzi do publicznej dokumentacji. Dane strony wskazują jako cel https://docs.devpubs.apple.com/drafts/f16-dspector-161940504-rapid-isa-adoption-documentation/documentation/xcode/enabling-enhanced-security-for-your-app, czyli hosta, którego nie da się rozwiązać spoza Apple.¹ Z kolei publiczny artykuł pod odpowiadającą ścieżką, Włączanie enhanced security w aplikacji, o 10:40 czasu PT nie wspomina ani o arm64e.x1, ani o CPA2; wciąż dokumentuje ustawienia kompilacji tej funkcji, od ENABLE_POINTER_AUTHENTICATION po CLANG_ENABLE_STACK_ZERO_INIT.⁵

Informacje o wydaniu Xcode 27 RC zawierają odpowiadający wpis w sekcji Enhanced Security od premiery RC 9 września i to właśnie on nazywa mechanizm:

arm64e.x1, czyli wycinek Hardware-Checked Pointer Arithmetic, realizuje uprawnienie Check for Overflow of Pointer Arithmetic, sprawdzając przepełnienie do znaczników pamięci, co zapewnia dodatkową ochronę ponad Memory Integrity Enforcement. (152104701)¹⁰

Wycinek nie był tajemnicą. 9 września o 13:40 czasu PT badacz publikujący jako Longhorn napisał, że „Apple M6/A20 ship with FEAT_CPA2 - checked pointer arithmetic - and there’s a new executable type for it”, i zacytował zdanie, które — jak się okazuje — pochodzi z dokumentu ukrytego wewnątrz Xcode.¹¹ Informacje dla iOS i watchOS nadrobiły zaległość dwa dni później.

Wycinek w SDK i w kompilatorze

SDK systemu iOS w Xcode 27.0 (kompilacja 27A266a) definiuje podtyp w pliku 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)

Komentarz nad makrem pomocniczym zdradza, dokąd zmierza ta systematyka: „Obecne wycinki PAC obejmują ARM64E oraz ARM64E_X1. Przyszłe wycinki mogą kontynuować tę konwencję.”⁶

Apple clang 21.0.0 (clang-2100.3.34.2), kompilator z tej wersji Xcode, przyjmuje -arch arm64e.x1 i traktuje go jak inny procesor. Z opcją -### zgłasza -target-cpu apple-a20 oraz listę funkcji zawierającą +cpa, +mte, +pauth, +pauth-lr i +fpac. Samo -arch arm64e zgłasza -target-cpu apple-a12 i żadnego +cpa.² Nagłówek pliku obiektowego zapisuje podtyp jako E.X1, a lipo -info nazywa tę architekturę arm64e.x1.

Różnica sprowadza się do jednego mnemonika. Weźmy funkcję dodającą indeks do wskaźnika:

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

Zbudowane z -O2 dla arm64e ciało funkcji to jedno add i powrót. Zbudowane dla arm64e.x1 — add zamienia się w addpt:

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

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

Kompilacja nie wymagała żadnej flagi; wybór architektury włącza sprawdzaną arytmetykę.² Flaga istnieje dla kierunku odwrotnego oraz dla pozostałych wycinków. Pomoc clang wymienia -fchecked-pointer-arithmetic, opisaną jako „Enable checked pointer arithmetic, with software sequences if necessary”, oraz -fno-checked-pointer-arithmetic.² Z tą flagą zwykłe arm64e i arm64 otrzymują sekwencję programową: zwyczajne add, operację XOR na bazie i wyniku, test 10 najstarszych bitów, [63:54], względem 0xffc0000000000000, a gdy się różnią — movk wpisujące 0xc8a2 w 16 najstarszych bitów wskaźnika, co czyni go niekanonicznym. Z -fno-checked-pointer-arithmetic arm64e.x1 wraca do zwykłego add.²

Co sprawdza CPA2

Apple dołącza wewnątrz Xcode 27 dokument referencyjny dla swojego asystenta kodu i to on wyjaśnia tę kontrolę lepiej niż informacje o wydaniu. Pierwsze zdanie: „Sprawdzana arytmetyka wskaźników sprawia, że sprzęt obsługujący rozszerzenie FEAT_CPA2 wykrywa moment, w którym obliczenie wskaźnika przepełnia się z bitów adresu do starszych bitów wskaźnika.” Dokument tłumaczy, dlaczego najstarszy bajt ma znaczenie: „To właśnie przepełnienie do nich pozwala arytmetyce przejść z jednego obiektu do drugiego, wciąż przedstawiając znacznik akceptowany przez sprzęt.” Dalej: „Wykrywanie zachodzi w dwóch miejscach: jawna arytmetyka zatruwa swój wynik, a każdy load i store sprawdza dodawanie wykonywane w ramach swojego trybu adresowania.”³

Porównanie dotyczy najstarszych bajtów. „Kontrola porównuje najstarszy bajt wyniku, bity [63:56], z najstarszym bajtem argumentu bazowego. Bajt ten niesie 4-bitowy znacznik Memory Tagging Extension (MTE) w bitach [59:56], gdy MTE jest włączone.” Sprzęt zatruwa wskaźnik, który nie przejdzie kontroli, a to właśnie zatrucie naśladuje powyższa sekwencja programowa: „Zatruty wskaźnik jest celowo niekanoniczny, więc kolejna dereferencja powoduje błąd translacji poziomu 0, dostarczany jako EXC_ARM_CPA_FAIL (0x108) z ESR 0x92000004 (odczyt) lub 0x92000044 (zapis).”³

Instrukcja pochodzi od Arm. Łatka LLVM dodająca obsługę w asemblerze, scalona 30 listopada 2023 roku, opisuje Checked Pointer Arithmetic Extension, czyli FEAT_CPA, jako ogłoszone wraz z architekturą Armv9.5-A i dodaje instrukcje skalarne ADDPT, SUBPT, MADDPT oraz MSUBPT, a także formy wektorowe.¹² Zarówno informacje Apple, jak i jego dokument referencyjny mówią o CPA2 — rozszerzeniu włączającym, które musi obsługiwać sprzęt — a definicja z dokumentu referencyjnego brzmi tak, jak przytoczono wyżej.³

„MIE” z akapitu Apple to Memory Integrity Enforcement, które zespół bezpieczeństwa Apple ogłosił 9 września 2025 roku jako „naszą kompleksową obronę bezpieczeństwa pamięci dla platform Apple”, „wbudowaną wprost w sprzęt i oprogramowanie Apple we wszystkich modelach iPhone 17 oraz iPhone Air”, opartą na Enhanced Memory Tagging Extension (EMTE), które Apple opracowało wspólnie z Arm.⁸ Tamten wpis informował deweloperów, że mogą „zacząć testować tę potężną ochronę dla swojej aplikacji, w tym EMTE na obsługującym je sprzęcie, korzystając z ustawień Enhanced Security w Xcode”.⁸ CPA2 zamyka jedną konkretną lukę w znakowaniu. Znakowanie porównuje znacznik z najstarszego bajtu wskaźnika ze znacznikiem pamięci, której wskaźnik dotyka, zatem wskaźnik, który jedynie przechodzi do sąsiedniej alokacji, nie naruszając swojego najstarszego bajtu, mieści się w zasięgu znakowania: znaczniki się różnią, dostęp kończy się błędem. Arytmetyka przepełniająca się do najstarszego bajtu to przypadek, którego znakowanie nie widzi, ponieważ potrafi „wytworzyć wskaźnik, którego znacznik pasuje do innej alokacji”, a — słowami dokumentu referencyjnego — „bez tej kontroli to właśnie takie przepełnienie byłoby sposobem, w jaki atakujący pokonałby znakowanie”.³

Cztery przełączniki w Xcode 27

Dokument referencyjny nie owija w bawełnę: „W targecie aplikacji muszą być włączone cztery rzeczy. Pominięcie jednej oznacza brak ochrony.”³ Są to:

1. Ustawienie kompilacji ENABLE_HARDWARE_CHECKED_POINTER_ARITHMETIC_SLICE = YES, widoczne w Build Settings w sekcji Security jako „Enable Hardware-Checked Pointer Arithmetic Slice”. Występuje ono w specyfikacji systemu kompilacji Xcode 27 RC.³⁷
2. Uprawnienie Enhanced Security, com.apple.security.hardened-process, dodawane przez odpowiednią capability w Signing & Capabilities.
3. Sprzętowe znakowanie pamięci, com.apple.security.hardened-process.checked-allocations, czyli opcja Memory Safety „Enable Hardware Memory Tagging”.
4. Uprawnienie egzekwujące, com.apple.security.hardened-process.checked-allocations.enforce-checked-pointer-arithmetic-overflow, czyli opcja „Enforce Checking for Overflow of Pointer Arithmetic”.

„Wiersz 4 jest podopcją wiersza 3, a wiersz 3 — wiersza 2.”³ Znakowanie jest konieczne, ponieważ najstarszy bajt musi przechowywać coś, co warto porównywać.

Ustawienie kompilacji robi jedno: „dopisuje arm64e.x1 do ARCHS_STANDARD”. To z kolei ma własny warunek wstępny: „Ustawienie nie działa, jeśli ARCHS zostanie nadpisane wartością nieopartą na ARCHS_STANDARD.” Ręcznie pisany plik uprawnień wymaga jeszcze jednego klucza: „Wiersz 2 potrzebuje dodatkowo com.apple.security.hardened-process.enhanced-security-version-string = 2; Xcode zapisuje ten klucz przy dodawaniu capability, więc przy bezpośredniej edycji pliku uprawnień trzeba wpisać go samodzielnie.” Zmierzoną tabelę z dokumentu dla targetu iOS warto zapamiętać.³

Należy wybrać ostatni wiersz. Przy włączonym wycinku i wyłączonym uwierzytelnianiu wskaźników urządzenie bez CPA2 cofa się do samego arm64 i traci uwierzytelnianie wskaźników, które miałoby w przeciwnym razie.³ Wynik można sprawdzić tak, jak robi to dokument:

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

Trzy kolejne fakty z tego samego dokumentu powinny sąsiadować z tabelą. „__arm64e_x1__ to makro predefiniowane, dla kodu, który musi być kompilowany inaczej dla wycinka arm64e.x1.” Symulator nie wymaga niczego: „SDK symulatora nie definiują architektury arm64e.x1, więc system kompilacji usuwa ją z efektywnych architektur kompilacji na symulator dokładnie tak, jak robi to z arm64e.” Narzut w czasie wykonania Apple określa jako niski, a koszt lokuje w rozmiarze: „Kosztem jest rozmiar pliku binarnego: trzeci wycinek.”³ Biblioteki i frameworki potrzebują jedynie ustawienia kompilacji; uprawnienia system przyznaje per proces, wychodząc od głównego pliku wykonywalnego. Co więcej, biblioteka dostarczana wyłącznie jako arm64e i tak zyskuje, gdy wczyta ją aplikacja z włączonym egzekwowaniem: „instrukcje load/store w bibliotece nadal będą sprawdzane”.³

Zmiany w kodzie: „Zasadniczo żadne. Kompilator emituje sprawdzane instrukcje w wycinku arm64e.x1, a sprzęt egzekwuje je, gdy tylko uprawnienia z sekcji »How to Enable« są na miejscu.”³ Wyjątkiem są wzorce, których arytmetyka narusza najstarszy bajt, a dokument je wylicza: różnica między wskaźnikami do dwóch alokacji, przesunięcie przeniesione poza koniec obiektu, arytmetyka na bazie NULL oraz wskaźniki o typie całkowitym w obliczeniach. Uwaga o stabilności mieści się w jednym zdaniu: „kod z utajonymi błędami arytmetyki wskaźników ulegnie awarii”. Dokument ostrzega, że instrukcja zatruwająca i błędna dereferencja „mogą znajdować się w różnych funkcjach, plikach lub bibliotekach”.³ Xcode ostrzega podczas kompilacji, jeśli uprawnienie egzekwujące ustawiono w targecie, który nie buduje wycinka; dokument nazywa to ostrzeżenie „jedynym sygnałem, że konfiguracja jest niekompletna”.³

Kto ma ten sprzęt

Lista Apple wymienia układy, a wrześniowe premiery przypisują je do produktów. A20 Pro znajduje się w iPhone 18 Pro i iPhone 18 Pro Max, „all powered by A20 Pro”, oraz w iPhone Duo, „Powered by the new A20 Pro”.⁹ S11 to układ w Apple Watch Series 12 i Apple Watch Ultra 4.⁹ M6 Apple ogłosiło 25 sierpnia w Mac mini, w komunikacie zatytułowanym „Apple unveils a more powerful Mac mini featuring the all-new M6 and M5 Pro”.⁹ Ogłoszone to jeszcze nie to samo co dostępne: według terminów Apple iPhone 18 Pro i nowe zegarki trafiają do sklepów 18 września, Mac mini 22 września, a iPhone Duo 23 października.⁹ Własna lista platform w dokumencie referencyjnym wymienia iOS na A20 Pro i watchOS na S11, a o komputerach Mac milczy, choć informacje o wydaniu je uwzględniają.³ Układy A19 i A19 Pro w iPhone 17 oraz iPhone Air obsługują Memory Integrity Enforcement, ale nie ma ich na liście arm64e.x1, więc gdyby kompilacja włączyła tę flagę dla arm64e, telefony te wykonywałyby sekwencję programową, a nie addpt.¹⁸ W przypadku komputerów Mac wpis Xcode 27 porzuca Intela omawia drugą zmianę ARCHS_STANDARD w tym wydaniu: usunięcie x86_64 przy docelowej wersji wdrożenia 27.0.

Dla każdego, kto tworzy dla iPhone Duo, ten wycinek jest pierwszą istotną dla Duo zmianą w łańcuchu narzędzi, która nie czeka na SDK iOS 27.1. Znajduje się w Xcode 27 RC już dziś, a Duo ze swoim A20 Pro trafia na listę egzekwowania od pierwszego dnia sprzedaży. Wpis Przygotuj aplikację na iPhone Duo prowadzi jedną prawdziwą aplikację przez każdą pozycję urządzenia i przez cały proces zgłoszenia do App Store.

Co zrobiłbym ja

W każdej aplikacji, która już przyjęła Enhanced Security, warto włączyć ostatni wiersz tabeli, a uprawnienie egzekwujące dodać najpierw w osobnej gałęzi. Gdy sprzęt już będzie pod ręką, każde EXC_ARM_CPA_FAIL należy traktować jak zgłoszenie błędu dotyczące arytmetyki wskaźników i szukać miejsca zatrucia, a nie miejsca awarii. Flagi na arm64e lepiej nie ruszać: sekwencja programowa kosztuje instrukcje przy każdym dodawaniu wskaźnika, a lepszym zakładem jest sam wycinek. Dopóki Apple nie opublikuje artykułu, do którego prowadzą jego informacje o wydaniu, dokument referencyjny wewnątrz Xcode pozostaje najpełniejszym opisem, jaki firma dostarczyła.

Najważniejsze wnioski

Dla inżynierów iOS i macOS: - arm64e.x1 to podtyp CPU 12 w Mach-O; clang celuje dla niego w apple-a20 z +cpa i kompiluje arytmetykę wskaźników do addpt. - Egzekwowanie wymaga czterech przełączników: ustawienia kompilacji wycinka, Enhanced Security, sprzętowego znakowania pamięci oraz uprawnienia dotyczącego przepełnienia. Buduje się arm64 arm64e arm64e.x1.

Dla osób odpowiedzialnych za bezpieczeństwo i platformę: - Przy włączonym egzekwowaniu sprawdzane instrukcje arytmetyczne porównują najstarszy bajt wyniku z najstarszym bajtem bazy i zatruwają przy niezgodności, zamykając arytmetyczne obejście znakowania pamięci; obliczenia adresów w load i store również podlegają kontroli, nawet w zwykłych bibliotekach arm64e wczytanych przez aplikację z egzekwowaniem. - Ogłoszony zgodny sprzęt: A20 Pro (iPhone 18 Pro, iPhone Duo), M6 (Mac mini), S11 (Watch Series 12 i Ultra 4). iPhone 17 nie znalazł się na liście; urządzenia trafiają do sklepów od 18 września.

Dla śledzących dokumentację Apple: - Akapit z informacji o wydaniu prowadzi do wewnętrznego hosta roboczego, a publiczny artykuł pozostaje w tyle; dołączony do Xcode 27 RC dokument referencyjny jest na razie kompletnym źródłem.

Często zadawane pytania

Czy arm64e.x1 zastępuje arm64e?

Nie. Własna zmierzona tabela Apple wskazuje jako zalecaną konfigurację arm64 arm64e arm64e.x1, a dokument referencyjny mówi, że target budujący wycinek x1 bez uwierzytelniania wskaźników nie dostarcza w ogóle wycinka arm64e, przez co starsze urządzenia tracą uwierzytelnianie wskaźników.³

Czy trzeba zmieniać kod?

Zwykle nie. Kompilator emituje sprawdzane instrukcje, a sprzęt egzekwuje je, gdy tylko uprawnienia są na miejscu. Kod, którego arytmetyka wskaźników narusza najstarszy bajt wskaźnika — różnice między wskaźnikami do odrębnych alokacji, przesunięcia przeniesione daleko poza koniec obiektu czy arytmetyka na bazie NULL — przy włączonym egzekwowaniu kończy się błędem, i o to właśnie chodzi; dokument referencyjny Apple mówi o takim kodzie, że „ulegnie awarii”.³

Które urządzenia to egzekwują?

Zgodnie z informacjami o wydaniu: modele iPhone’a z układem A20 Pro lub nowszym, komputery Mac z układem M6 lub nowszym oraz modele Apple Watch z układem S11 lub nowszym.¹ Na pozostałych urządzeniach program ładujący nie wybiera tego wycinka i nic się nie zmienia.

Czy CPA2 to to samo co FEAT_CPA firmy Arm?

Nie. Rejestr funkcji Arm wymienia FEAT_CPA jako „Instruction-only Checked Pointer Arithmetic”, a FEAT_CPA2 jako „Checked Pointer Arithmetic”: pierwsze dostarcza rodzinę instrukcji ADDPT, które emituje clang, drugie zaś jest sprzętową obsługą samej kontroli.¹³¹² Apple wskazuje jako wymóg CPA2, a jego dokument referencyjny mówi o A20 Pro i S11: „Oba układy obsługują FEAT_CPA2, w które celuje wycinek arm64e.x1.”³

Źródła