“Apple Silicon” 애플 맥 Intel 기반에서 ARM 기반으로 전환 예고

개발자 관점에서의 변화

Apple이 아키텍처 전환을 하는 것은 이번이 처음이 아닙니다 ^[1].
이미 이전에도 PowerPC 기반에서 현재의 Intel 기반으로 “성공적으로” 대전환을 한 경험이 있죠.
그런만큼 Universal Binary와 Rosetta 기술을 활용하여 전환 과정이 개발자와 사용자 모두에게 seamless 할 것이라고 예상됩니다.

Universal Binary는 x86_64와 arm64으로 컴파일 된 두 가지의 바이너리를 모두 담고 있는 단일 바이너리 포맷입니다.
앱스토어에서 받을 때는 해당되는 아키텍처의 바이너리만 다운로드 되어 용량을 줄이고, 직접 설치 시 운영체제가 필요 없는 부분을 삭제하여 용량을 확보합니다.

Rosetta는 Binary Translation, 즉 Intel 아키텍처 용으로 컴파일 된 프로그램을 ARM 아키텍처 용으로 변환하는 역할을 합니다.
AOT (Ahead-Of-Time) 컴파일 기법을 활용하여 프로그램을 미리 정적(static)으로 변환하는 과정을 거쳐서 제공하거나,
JIT (Just-In-Time) 컴파일을 사용하는 복잡한 프로그램의 경우에는 JIT으로 생성된 Intel 코드를 ARM 코드로 동적(dynamic)으로 변환하여 지원합니다.

최근 macOS 생태계에서 대부분의 개발은 JavaScript와 같은 웹 기술 기반으로 이루어지거나, Xcode를 활용하여 프로젝트를 빌드합니다.
개발자의 경우에는 기존 앱의 코드를 Apple에서 제공하는 툴체인을 사용하여 다시 빌드하게 되면 자동으로 두 플랫폼에서 작동하는 Universal 앱을 만들 수 있습니다.
사용자 입장에서는 기존과 마찬가지로 앱스토어에서 앱을 설치하면 본인의 플랫폼에 최적화 된 버전으로 사용할 수 있습니다.

또한, iOS 및 iPad 앱을 더욱 편하게 구동할 수 있게 됨으로써 기존 유용한 iOS 앱들이 macOS에서도 사용될 것으로 예상됩니다.

요약정리

• 대부분의 개발자들은 이번 아키텍처 전환에 큰 영향을 받지 않을 것으로 예상됨
• Apple에서는 Universal Binary와 Rosetta 기술을 통해 더 매끄러운 전환을 꾀하고 있음
• Apple 자체적으로 만드는 하드웨어와 소프트웨어의 조합으로 저전력/고성능을 기대해볼 수 있음

해커 관점에서의 변화

보통 해커들은 주어진 툴이나 환경에서만 작업하지 않습니다.
아키텍처에 의존성이 생길 수 있는 로우레벨 기능들을 자주 활용하게 되는데요.

해킹에 활용되는 툴 대부분이 python이나 ruby 같은 스크립트 언어 레벨에서 구현 되어 있지만, 간혹 로우레벨 API에 대한 액세스나 아키텍처 의존성이 있는 assembly 코드를 직접 작성한 코드를 컴파일 해야하는 라이브러리가 존재합니다.

이번 Apple의 행보는 Intel 아키텍처가 주류였던 시점에 PowerPC에서 Intel로 전환한 것과는 사뭇 다른 느낌입니다.
물론 최근들어 모바일이나 임베디드 기기에서는 ARM 아키텍처가 무척 많이 사용되지만, 여전히 랩탑과 데스크탑에서는 Intel이 주류이기 때문입니다.

그 중에서도 가장 문제가 될 것으로 예상되는 부분은 바로 “가상화” 그리고 “에뮬레이션” 입니다.
우선, 잘 알려진 사실은 아니지만 Intel의 명령어 아키텍처(ISA)는 수 많은 특허로 보호되어 있습니다.
실제로 2017년에 Microsoft와 Qualcomm이 ARM 운영체제에서 x86 에뮬레이션을 시도했고, Intel로부터 법적 소송을 암시하는 경고를 받기도 했습니다 ^[2][3]. 다행히 Apple에서 Rosetta2를 선보였다는 점에서 Intel과 합의가 되었거나 특허만료된 명령어 셋만 지원하는 방향으로 지원할 것으로 예상됩니다.

물론, x86 에뮬레이션 시도가 더이상 진전되지 않은 것은 법적 문제 뿐만은 아닙니다.
성능면에서 실제로 사용하기에는 터무니 없이 부족했던 것이 가장 큰 문제였습니다.
현재 VMWare나 Parallels 같은 가상화 솔루션들은 x86 host위에서 x86 guest를 가상화하는 native virtualization을 활용합니다.
그럼에도 성능면에서 오버헤드가 발생하는데, arm64 host에서 x86 guest를 에뮬레이션하게 된다면 엄청나게 느릴것 입니다.

WWDC 발표에서도 시연했듯이, ARM 기반 가상화는 지원하기 때문에 ARM guest 운영체제 (리눅스..)를 돌리는 것은 어려움이 없을 것 같습니다. 하지만, 그게 얼마나 유용할지는 다른 문제인 것이죠.

요약정리

• 네이티브 툴의 부재로 Intel 프로그램 분석이나 디버깅이 어려울 수 있음
• Intel 아키텍처 버전의 Windows를 현실적으로 사용할 수 없게 됨
• 하지만, iPhone과 사실상 같은 아키텍처이기에 iOS 취약점 연구 및 분석을 하는데에는 더 용이할 수 있음

예상되는 보안 기능

Apple이 이번 WWDC 2020에서 Apple Silicon에 대해서 발표한 내용에 소개된 몇 가지 보안 기능에 대해서 간략하게 설명합니다 ^[4].

W^X

• 메모리 영역을 동시에 쓰기가능(Writable)과 실행가능(eXecutable) 하지 않도록 하는 보안 기술
• pthread_jit_write_protect_np API 추가를 통해 빠른 thread 별 메모리 영역 퍼미션 조정이 가능해짐
  • Just-In-Time (JIT) 컴파일러의 보안성 및 사용성 확장

Kernel Integrity Protection

• 하드웨어를 통해 커널 변조를 제한하는 보안 기술
• 커널이 초기화 된 이후에는 커널 코드가 포함된 메모리 페이지를 변경할 수 없고, 새로운 실행 가능한 영역을 할당할 수 없음
  • 커널 코드 인젝션 공격에 대한 방어

Pointer Authentication Codes (PAC)

• 이미 iOS에서는 적용된 기술로, 메모리 포인터를 “서명”하여 포인터 변조를 통한 임의 코드실행 공격을 방어하는 보안 기술
  • 64-bit 포인터 값에서 사용되지 않는 상위 비트들을 활용하여 PAC 값을 저장
  • arm64e의 특정 명령어(instruction)를 실행해서 서명해야 하므로, 임의 코드실행이 불가능하다면 임의의 포인터 값에 대한 PAC 생성 불가능
• 적용 대상
  • 커널, 시스템 애플리케이션, 시스템 서비스
  • 장기적으로 3rd-party 애플리케이션에도 적용할 수 있도록 할 예정

Device Isolation

• 컴퓨터에 연결된 장비 별로 각각의 IOMMU를 사용하여 메모리 권한 분리를 강화하는 보안 기술

Secure Boot

• iOS와 마찬가지로 부트로더에서 로드 되는 운영체제의 서명 값을 검사하여 Apple이 서명한 운영체제나 리커버리 이미지만 구동될 수 있도록 변경
  • 여러 macOS 인스턴스 설치 가능 / 다른 버전의 macOS 설치 및 관리 가능
• Full Security 모드 vs Reduce Security 모드
  • Full Security 모드에서는 위에 설명한대로 Apple이 서명한 운영체제만 구동 가능하며, 3rd-party 커널 익스텐션 설치 불가능
  • Reduced Security 모드는 현재 상황과 거의 동일함
• 설치된 macOS 별로 각각 다른 Security Policy 적용 가능
  • 기존 system-wide 정책 적용에서 변경