arm64e.x1: Apple의 검사된 포인터 연산 슬라이스

arm64e.x1이란 무엇입니까? CPU 서브타입 12를 갖는 새로운 Mach-O 슬라이스로, Apple이 9월 11일 iOS 27 RC 릴리스 노트에서 단 한 문단으로 소개한 것입니다. 노트에 따르면 A20 Pro 이상 칩을 탑재한 iPhone, M6 이상 칩을 탑재한 Mac, S11 이상 칩을 탑재한 Apple Watch에서 이 슬라이스는 “더 강력한 MIE 보호를 위한 CPA2를 포함해 하드웨어 보안 및 성능 명령을 추가로 도입”합니다.¹ 이 슬라이스에서 Apple clang 21은 일반적인 포인터 연산을 Arm의 addpt 명령으로 컴파일합니다. 이 명령은 연산 결과가 메모리 태그가 자리한 포인터 최상위 바이트로 넘쳐 들어가면 해당 포인터를 오염(poison)시켜, 하드웨어가 받아들일 태그를 연산 결과가 갖지 못하게 만듭니다. Xcode 27은 빌드 설정 하나로 이 슬라이스를 추가하며, 런타임 강제는 Enhanced Security 엔타이틀먼트와 그 아래 두 개의 엔타이틀먼트로 통제합니다.²³

요약: 이 문단은 제 워처가 오전 10시 01분(PT)에 확인했을 때 iOS와 watchOS 27 RC 노트에, 오전 11시 12분에는 macOS 노트에 도달해 있었습니다. “Learn more” 링크는 Apple 내부의 초안 호스트를 가리키며, 공개된 Enhanced Security 문서에는 아직 이 슬라이스가 언급되지 않습니다.¹⁴⁵ 반면 Xcode 27 RC는 이미 필요한 것을 모두 담고 있습니다. 서브타입 상수, +cpa와 함께 apple-a20을 타깃하는 컴파일러, 빌드 설정, 그리고 네 가지 스위치를 명시한 참조 문서입니다.⁶²⁷³ 발표된 하드웨어는 iPhone 18 Pro와 iPhone Duo(A20 Pro), M6 탑재 Mac mini, Apple Watch Series 12와 Ultra 4(S11)이며, iPhone 17 제품군은 목록에 없습니다.¹⁹ 세 슬라이스를 모두 빌드하고 포인터 인증은 켜 둔 채로 두십시오. 그리고 원인이 된 연산과는 한참 떨어진 곳에서 크래시가 발생하리라고 예상하십시오.

9월 17일 업데이트: macOS 26.6에서의 App Store 업로드 차단

Apple은 제가 문서 JSON을 9월 16일과 9월 17일에 가져온 사이에 Xcode 27 릴리스 노트의 Enhanced Security 섹션에 알려진 문제 하나를 추가했습니다. “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.”(Hardware-Checked Pointer Arithmetic Slice 기능을 켠 앱은 Xcode 자동 서명이 켜진 macOS Tahoe 26.6에서 App Store에 업로드할 수 없다) Apple이 제시하는 우회책은 이렇습니다. “Distribute with macOS 27 and Xcode 27 or use manual signing.”(macOS 27과 Xcode 27로 배포하거나 수동 서명을 사용하라)¹⁴ 그러니 arm64e.x1 슬라이스를 담은 빌드에는 Xcode 27이 지원하는 최소 호스트에서 배포 비용이 따릅니다. Xcode 27이 요구하는 최소 버전인 Tahoe 26.6에 아직 머물러 있는 Mac은 그 빌드를 자동 서명으로 업로드할 수 없습니다. Apple의 노트대로라면 수동 서명이나 macOS 27 호스트가 이를 해결해 주지만, 저에게는 macOS 27 머신이 없어 두 경로 모두 시도해 보지 못했습니다.¹⁴

무엇이, 어디에 나타났는가

iOS 및 iPadOS 27 RC 릴리스 노트에 Hardware Security라는 제목의 섹션이 생겼고, 그 New Features 하위 제목 아래에 문제의 문단이 놓였습니다. 전문은 다음과 같습니다.

arm64e.x1은 더 강력한 MIE 보호를 위한 CPA2를 포함해 하드웨어 보안 및 성능 명령을 추가로 도입합니다. arm64e.x1을 지원하는 기기에는 A20 Pro 이상 칩을 탑재한 iPhone 모델, M6 이상 칩을 탑재한 Mac 컴퓨터, S11 이상 칩을 탑재한 Apple Watch 모델이 포함됩니다. Xcode에서는 enhanced security 창과 빌드 설정을 통해 arm64e.x1과 CPA2를 사용할 수 있습니다. 자세한 내용은 Enhanced Security 문서를 참고하십시오. (152103975)¹

watchOS 27 RC 노트에도 같은 확인 시점에 같은 문단이 추가돼 있었습니다. macOS 27 RC 노트에는 오전 10시 02분(PT)까지 없었지만, 정작 그 문단은 M6 이상 Mac을 명시하고 있습니다. 오전 11시 12분(PT)이 되자 macOS 노트에도 같은 링크와 함께 문단이 실렸습니다.⁴ 제 워처는 이 세 페이지를 몇 분 간격으로 가져오는데, 세 페이지 모두 9월 9일 이후 변화가 없던 상태였습니다.

이 문단에서 눈여겨볼 대목이 두 가지 있습니다. 첫째, “Learn more” 링크는 공개 문서로 연결되지 않습니다. 페이지 데이터가 밝히는 대상은 https://docs.devpubs.apple.com/drafts/f16-dspector-161940504-rapid-isa-adoption-documentation/documentation/xcode/enabling-enhanced-security-for-your-app이며, Apple 외부에서는 이름 해석조차 되지 않는 호스트입니다.¹ 둘째, 같은 경로에 대응하는 공개 문서 앱에 enhanced security 활성화하기에는 오전 10시 40분(PT) 기준으로 arm64e.x1도 CPA2도 언급돼 있지 않습니다. 이 문서는 여전히 ENABLE_POINTER_AUTHENTICATION부터 CLANG_ENABLE_STACK_ZERO_INIT까지 해당 기능의 빌드 설정만 다룹니다.⁵

Xcode 27 RC 릴리스 노트에는 RC가 공개된 9월 9일부터 Enhanced Security 항목 아래에 대응하는 내용이 실려 있었고, 메커니즘의 이름을 밝힌 쪽은 오히려 이쪽입니다.

arm64e.x1, 즉 Hardware-Checked Pointer Arithmetic 슬라이스는 메모리 태그로의 오버플로를 검사함으로써 Check for Overflow of Pointer Arithmetic 엔타이틀먼트를 포함하며, Memory Integrity Enforcement 위에 추가 보호를 제공합니다. (152104701)¹⁰

이 슬라이스가 비밀이었던 것은 아닙니다. 9월 9일 오후 1시 40분(PT), Longhorn이라는 이름으로 글을 올리는 연구자가 “Apple M6/A20은 검사된 포인터 연산인 FEAT_CPA2를 탑재하며, 이를 위한 새로운 실행 파일 유형이 있다”고 쓰면서 한 문장을 인용했습니다. 그 문장은 나중에 Xcode 내부 문서에서 나온 것으로 밝혀졌습니다.¹¹ iOS와 watchOS 노트가 뒤따른 것은 그로부터 이틀 뒤였습니다.

SDK와 컴파일러에서 본 슬라이스

Xcode 27.0(빌드 27A266a)의 iOS SDK는 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)

헬퍼 매크로 위의 주석은 이 분류 체계가 어디로 향하는지 알려 줍니다. “현재의 PAC 슬라이스에는 ARM64E와 ARM64E_X1이 포함된다. 향후 슬라이스도 이 관례를 이어갈 수 있다.”⁶

그 Xcode에 들어 있는 컴파일러인 Apple clang 21.0.0(clang-2100.3.34.2)은 -arch arm64e.x1을 받아들이고 이를 다른 CPU로 취급합니다. -###를 붙이면 -target-cpu apple-a20을 출력하고, 기능 목록에는 +cpa, +mte, +pauth, +pauth-lr, +fpac가 포함됩니다. 그냥 -arch arm64e를 주면 -target-cpu apple-a12가 나오고 +cpa는 없습니다.² 오브젝트 파일 헤더에는 서브타입이 E.X1로 기록되며, lipo -info는 아키텍처를 arm64e.x1이라고 부릅니다.

차이는 니모닉 하나입니다. 포인터에 인덱스를 더하는 함수를 예로 들어 보겠습니다.

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

arm64e용으로 -O2로 빌드하면 본문은 add 하나와 리턴뿐입니다. arm64e.x1용으로 빌드하면 그 add가 addpt로 바뀝니다.

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

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

이 빌드에는 플래그가 필요하지 않았습니다. 아키텍처를 고르는 것만으로 검사된 연산이 켜집니다.² 플래그는 반대 방향을 위해, 그리고 다른 슬라이스를 위해 존재합니다. clang 도움말에는 “필요하다면 소프트웨어 시퀀스를 써서 검사된 포인터 연산을 활성화한다”라고 설명된 -fchecked-pointer-arithmetic과, -fno-checked-pointer-arithmetic이 나열돼 있습니다.² 이 플래그를 주면 일반 arm64e와 arm64에서는 소프트웨어 시퀀스가 생성됩니다. 평범한 add, 베이스와 결과의 배타적 논리합, 상위 10비트 [63:54]를 0xffc0000000000000과 대조하는 테스트, 그리고 값이 다를 때 포인터 상위 16비트에 0xc8a2를 써 넣어 포인터를 비정규(non-canonical) 상태로 만드는 movk입니다. -fno-checked-pointer-arithmetic을 주면 arm64e.x1도 평범한 add로 되돌아갑니다.²

CPA2는 무엇을 검사하는가

Apple은 Xcode 27 안에 코딩 어시스턴트용 참조 문서를 함께 넣어 두었는데, 이 검사에 관해서는 릴리스 노트보다 그 문서가 훨씬 잘 설명합니다. 첫 문장은 이렇습니다. “검사된 포인터 연산은 FEAT_CPA2 확장을 지원하는 하드웨어가, 포인터 계산이 주소 비트를 넘어 포인터 상위 비트로 오버플로하는 순간을 감지하게 한다.” 문서는 최상위 바이트가 왜 중요한지도 밝힙니다. “그 비트로 넘쳐 들어가는 것이야말로, 하드웨어가 받아들이는 태그를 그대로 유지한 채 연산이 한 객체에서 다른 객체로 걸어 들어가게 만드는 통로다.” 이어서 “감지는 두 곳에서 일어난다. 명시적 연산은 그 결과를 오염시키고, 모든 로드와 스토어는 주소 지정 모드의 일부로 수행하는 덧셈을 검사한다”고 적혀 있습니다.³

비교 대상은 최상위 바이트끼리입니다. “이 검사는 결과의 최상위 바이트, 비트 [63:56]을 베이스 오퍼랜드의 최상위 바이트와 비교한다. MTE가 활성화돼 있으면 그 바이트는 비트 [59:56]에 4비트 Memory Tagging Extension(MTE) 태그를 담고 있다.” 검사에 실패한 포인터는 하드웨어가 오염시키며, 바로 그 오염을 앞서 본 소프트웨어 시퀀스가 흉내 내는 것입니다. “오염된 포인터는 의도적으로 비정규 상태가 되므로, 다음 역참조에서 레벨 0 변환 폴트가 발생하고 EXC_ARM_CPA_FAIL(0x108)로 전달되며 ESR은 0x92000004(읽기) 또는 0x92000044(쓰기)가 된다.”³

명령 자체는 Arm에서 왔습니다. 어셈블러 지원을 추가한 LLVM 패치는 2023년 11월 30일에 병합됐고, Checked Pointer Arithmetic Extension, 즉 FEAT_CPA를 Armv9.5-A 아키텍처와 함께 발표된 것으로 설명하면서 스칼라 명령 ADDPT, SUBPT, MADDPT, MSUBPT와 벡터 형태를 추가합니다.¹² Apple의 노트와 참조 문서는 둘 다 하드웨어가 지원해야 하는 활성화 확장인 CPA2를 지목하며, 그 정의는 위에 인용한 그대로입니다.³

Apple의 문단에 나오는 “MIE”는 Memory Integrity Enforcement로, Apple 보안팀이 2025년 9월 9일에 “Apple 플랫폼을 위한 포괄적 메모리 안전 방어”라고 발표했고 “iPhone 17과 iPhone Air 전 모델에서 Apple 하드웨어와 소프트웨어에 곧바로 내장돼 있다”고 설명한 기술입니다. 그 토대는 Apple이 Arm과 함께 개발한 Enhanced Memory Tagging Extension(EMTE)입니다.⁸ 당시 게시물은 개발자들에게 “Xcode의 Enhanced Security 설정을 사용하면, 지원 하드웨어에서의 EMTE를 포함해 이 강력한 보호를 자신의 앱에서 시험해 볼 수 있다”고 안내했습니다.⁸ CPA2는 태깅이 가진 특정한 빈틈 하나를 막습니다. 태깅은 포인터 최상위 바이트의 태그와 접근하는 메모리의 태그를 비교합니다. 따라서 최상위 바이트를 건드리지 않은 채 이웃 할당 영역으로 넘어간 포인터는 태깅이 감당하는 사례입니다. 태그가 다르고, 접근은 폴트를 냅니다. 태깅이 볼 수 없는 것은 최상위 바이트로 오버플로하는 연산 쪽입니다. 그런 연산은 “다른 할당 영역과 일치하는 태그를 가진 포인터를 만들어 낼” 수 있고, 참조 문서의 표현대로 “이 검사가 없다면 바로 그 오버플로가 공격자가 태깅을 무력화하는 방법”이기 때문입니다.³

Xcode 27의 네 가지 스위치

참조 문서는 단도직입적입니다. “앱 타깃에서 네 가지를 활성화해야 한다. 하나라도 빠지면 보호는 없다.”³ 네 가지는 다음과 같습니다.

1. 빌드 설정 ENABLE_HARDWARE_CHECKED_POINTER_ARITHMETIC_SLICE = YES. Build Settings의 Security 아래에 “Enable Hardware-Checked Pointer Arithmetic Slice”로 표시되며, Xcode 27 RC의 빌드 시스템 명세에 실제로 존재합니다.³⁷
2. Enhanced Security 엔타이틀먼트 com.apple.security.hardened-process. Signing & Capabilities에서 해당 capability를 추가해 넣습니다.
3. 하드웨어 메모리 태깅 com.apple.security.hardened-process.checked-allocations. Memory Safety의 “Enable Hardware Memory Tagging” 옵션입니다.
4. 강제용 엔타이틀먼트 com.apple.security.hardened-process.checked-allocations.enforce-checked-pointer-arithmetic-overflow. “Enforce Checking for Overflow of Pointer Arithmetic” 옵션입니다.

“4행은 3행의 하위 옵션이고, 3행은 2행의 하위 옵션이다.”³ 태깅이 반드시 필요한 이유는, 최상위 바이트에 비교할 만한 값이 들어 있어야 하기 때문입니다.

빌드 설정이 하는 일은 하나뿐입니다. “ARCHS_STANDARD에 arm64e.x1을 덧붙인다.” 여기에는 전제 조건이 따릅니다. “ARCHS가 ARCHS_STANDARD에 기반하지 않은 값으로 덮어써져 있으면 이 설정은 아무 효과가 없다.” 그리고 엔타이틀먼트 파일을 직접 작성한다면 키가 하나 더 필요합니다. “2행에는 com.apple.security.hardened-process.enhanced-security-version-string = 2도 필요하다. capability를 추가하면 Xcode가 이 키를 써 주므로, 엔타이틀먼트 파일을 직접 편집한다면 직접 적어야 한다.” iOS 타깃을 대상으로 문서가 실측한 표는 외워 둘 만합니다.³

써야 할 것은 마지막 행입니다. 슬라이스를 켜고 포인터 인증을 끄면, CPA2가 없는 기기는 일반 arm64로 되돌아가면서 원래라면 누렸을 포인터 인증까지 잃습니다.³ 결과는 문서가 하는 방식 그대로 확인하십시오.

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

같은 문서에서 이 표 옆에 나란히 두어야 할 사실이 세 가지 더 있습니다. “__arm64e_x1__은 미리 정의된 매크로로, arm64e.x1 슬라이스용으로 다르게 컴파일해야 하는 코드를 위한 것이다.” 시뮬레이터에는 아무것도 필요 없습니다. “시뮬레이터 SDK는 arm64e.x1 아키텍처를 정의하지 않으므로, 빌드 시스템은 시뮬레이터 빌드의 유효 아키텍처에서 arm64e와 똑같은 방식으로 이를 제거한다.” 그리고 Apple은 런타임 오버헤드를 낮다고 표현하면서 비용은 크기 쪽이라고 말합니다. “비용은 바이너리 크기, 즉 세 번째 슬라이스다.”³ 라이브러리와 프레임워크에는 빌드 설정만 있으면 됩니다. 엔타이틀먼트는 메인 실행 파일을 기준으로 시스템이 프로세스 단위로 부여하기 때문입니다. 게다가 arm64e만 담은 라이브러리라도 강제가 켜진 앱이 로드하면 혜택을 받습니다. “라이브러리 안의 load/store 명령도 여전히 검사된다.”³

코드 변경에 관해서는 이렇습니다. “일반적으로 없다. 컴파일러가 arm64e.x1 슬라이스에서 검사된 명령을 생성하고, ‘How to Enable’의 엔타이틀먼트가 갖춰지면 하드웨어가 이를 강제한다.”³ 예외는 연산이 최상위 바이트를 건드리는 패턴들이며, 문서는 이를 이렇게 나열합니다. 서로 다른 두 할당 영역을 가리키는 포인터의 차이, 객체 끝을 넘어 계속 들고 다니는 오프셋, NULL을 베이스로 삼는 연산, 그리고 정수 타입으로 다뤄지는 포인터가 낀 연산입니다. 안정성에 관한 언급은 한 문장뿐입니다. “잠재된 포인터 연산 버그가 있는 코드는 크래시한다.” 문서는 오염을 일으키는 명령과 폴트를 내는 역참조가 “서로 다른 함수, 파일, 라이브러리에 있을 수 있다”고 경고합니다.³ Xcode는 슬라이스를 빌드하지 않는 타깃에 강제용 엔타이틀먼트가 설정돼 있으면 빌드 시점에 경고를 냅니다. 문서는 그 경고를 “설정이 불완전하다는 유일한 신호”라고 부릅니다.³

어떤 하드웨어가 해당되는가

Apple이 제시한 것은 칩이고, 9월의 발표들이 이를 제품과 연결해 줍니다. A20 Pro는 iPhone 18 Pro와 iPhone 18 Pro Max에 들어 있으며 “모두 A20 Pro로 구동”된다고 표현됐고, iPhone Duo에도 “새로운 A20 Pro로 구동”된다고 적혀 있습니다.⁹ S11은 Apple Watch Series 12와 Apple Watch Ultra 4의 칩입니다.⁹ Apple은 M6를 8월 25일, “Apple, 완전히 새로운 M6와 M5 Pro를 탑재한 더 강력한 Mac mini 공개”라는 제목의 릴리스에서 Mac mini와 함께 발표했습니다.⁹ 발표됐다는 것과 손에 들어왔다는 것은 다릅니다. Apple이 밝힌 일정에 따르면 iPhone 18 Pro와 새 Watch는 9월 18일, Mac mini는 9월 22일, iPhone Duo는 10월 23일에 매장에 놓입니다.⁹ 참조 문서 자체의 플랫폼 목록은 A20 Pro의 iOS와 S11의 watchOS만 언급할 뿐, 릴리스 노트가 포함한 Mac에 대해서는 아무 말이 없습니다.³ iPhone 17과 iPhone Air의 A19 및 A19 Pro 칩은 Memory Integrity Enforcement를 구동하지만 arm64e.x1 목록에는 없습니다. 그러니 빌드가 arm64e에 대해 플래그를 켠다면 그 기기들에서 돌아가는 것은 addpt가 아니라 소프트웨어 시퀀스입니다.¹⁸ Mac에 대해서는 Xcode 27의 Intel 지원 중단이 이번 릴리스의 또 다른 ARCHS_STANDARD 변경, 즉 배포 대상 27.0에서 x86_64가 빠지는 변화를 다룹니다.

iPhone Duo를 겨냥해 개발하는 사람에게 이 슬라이스는 iOS 27.1 SDK를 기다리지 않아도 되는 첫 번째 Duo 관련 툴체인 변경입니다. 오늘 나와 있는 Xcode 27 RC에 이미 들어 있고, A20 Pro를 품은 Duo는 출시 첫날부터 강제 대상 목록에 올라 있습니다. iPhone Duo에 맞춰 앱 준비하기는 실제 앱 하나를 모든 자세와 제출 과정까지 따라가며 살펴봅니다.

제가 하려는 일

이미 Enhanced Security를 채택한 앱이라면 표의 마지막 행을 켜되, 강제용 엔타이틀먼트는 먼저 브랜치에서 추가해 보십시오. 하드웨어가 손에 들어오면 모든 EXC_ARM_CPA_FAIL을 포인터 연산에 관한 버그 리포트로 취급하고, 크래시가 난 지점이 아니라 오염이 일어난 지점을 찾으십시오. arm64e에서는 플래그를 건드리지 마십시오. 소프트웨어 시퀀스는 포인터 덧셈마다 명령을 소모하며, 걸 만한 쪽은 슬라이스입니다. Apple이 릴리스 노트가 가리키는 문서를 공개하기 전까지는, Xcode 안의 참조 문서가 Apple이 내놓은 가장 완전한 설명입니다.

핵심 정리

iOS 및 macOS 엔지니어를 위해: - arm64e.x1은 Mach-O CPU 서브타입 12입니다. clang은 이를 위해 +cpa와 함께 apple-a20을 타깃하고, 포인터 연산을 addpt로 컴파일합니다. - 강제에는 네 가지 스위치가 필요합니다. 슬라이스 빌드 설정, Enhanced Security, 하드웨어 메모리 태깅, 오버플로 엔타이틀먼트입니다. 빌드 대상은 arm64 arm64e arm64e.x1입니다.

보안 및 플랫폼 리드를 위해: - 강제가 걸리면 검사된 연산 명령이 결과의 최상위 바이트를 베이스의 최상위 바이트와 비교하고 불일치 시 오염시켜, 메모리 태깅에 대한 연산 우회 경로를 막습니다. 로드와 스토어의 주소 계산에도 검사가 적용되며, 강제 중인 앱이 로드한 일반 arm64e 라이브러리에서도 마찬가지입니다. - 발표된 호환 하드웨어는 A20 Pro(iPhone 18 Pro, iPhone Duo), M6(Mac mini), S11(Watch Series 12와 Ultra 4)입니다. iPhone 17은 목록에 없으며, 기기들은 9월 18일부터 매장에 풀립니다.

Apple 문서를 추적하는 분들을 위해: - 릴리스 노트 문단은 내부 초안 호스트로 연결되고 공개 문서는 그보다 뒤처져 있습니다. 지금으로서는 Xcode 27 RC에 동봉된 참조 문서가 완전한 출처입니다.

자주 묻는 질문

arm64e.x1이 arm64e를 대체합니까?

아닙니다. Apple이 직접 실측한 표는 권장 구성을 arm64 arm64e arm64e.x1로 제시하며, 참조 문서는 포인터 인증 없이 x1 슬라이스를 빌드한 타깃은 arm64e 슬라이스를 아예 포함하지 않는다고 밝힙니다. 그러면 구형 기기는 포인터 인증을 잃습니다.³

코드를 고쳐야 합니까?

대개는 그렇지 않습니다. 컴파일러가 검사된 명령을 생성하고, 엔타이틀먼트가 갖춰지면 하드웨어가 이를 강제합니다. 포인터의 최상위 바이트를 건드리는 연산을 담은 코드, 예컨대 서로 다른 할당 영역을 가리키는 포인터 사이의 차이, 객체 끝을 한참 넘어 들고 다니는 오프셋, NULL을 베이스로 삼는 연산 같은 것들은 강제 아래에서 폴트를 냅니다. 그것이 바로 이 기능의 목적입니다. Apple의 참조 문서는 그런 코드가 “크래시한다”고 말합니다.³

어떤 기기가 이를 강제합니까?

릴리스 노트에 따르면 A20 Pro 이상 칩을 탑재한 iPhone, M6 이상 Mac, S11 이상 Apple Watch입니다.¹ 그 밖의 기기에서는 로더가 이 슬라이스를 선택하지 않으므로 달라지는 것이 없습니다.

CPA2는 Arm의 FEAT_CPA와 같은 것입니까?

아닙니다. Arm의 기능 레지스트리는 FEAT_CPA를 “Instruction-only Checked Pointer Arithmetic”으로, FEAT_CPA2를 “Checked Pointer Arithmetic”으로 등재하고 있습니다. 앞의 것은 clang이 생성하는 ADDPT 계열 명령을 제공하고, 뒤의 것은 검사 자체를 위한 하드웨어 지원입니다.¹³¹² Apple이 요건으로 지목한 쪽은 CPA2이며, 참조 문서는 A20 Pro와 S11에 대해 “두 칩 모두 FEAT_CPA2를 지원하며, arm64e.x1 슬라이스는 이를 타깃한다”고 적고 있습니다.³

출처