Apple Exclaves에 관하여

 (medium.com/@randomaugustine)
1P by GN⁺ | ★ favorite | 댓글 1개
  • Apple의 Exclaves는 XNU 커널이 침해돼도 일부 민감 리소스를 별도 영역에 남겨두려는 격리 기능이며, M4·A18용 XNU 소스 공개로 구조 일부가 드러남
  • XNU는 Mach 기반이지만 실제 시스템 기능은 같은 특권 범위에 몰려 있어 모놀리식 커널처럼 동작하고, Exclaves는 Secure Enclave, PPL, SPTM으로 이어진 방어 심화 흐름 위에 있음
  • Exclaves는 부팅 시 정의되는 도메인과 리소스로 구성되며, 공유 메모리 버퍼, 오디오 버퍼, 센서, Conclave, 서비스 등을 SPTM의 새 페이지 타입으로 XNU에서 보호함
  • Secure Kernel(SK) 은 XNU와 같은 애플리케이션 프로세서에서 동작하며, 소스 단서상 seL4 계열 및 ARM TrustZone secure world 사용 가능성이 있지만 내부 구현 상당 부분은 공개되지 않음
  • 실제 보안 효과는 어떤 구성요소가 Exclaves로 이동하느냐에 달려 있으며, 현재 빌드 이미지는 카메라·마이크 보안 표시기, Apple Neural Engine 일부, 일부 드라이버, Secure Enclave 통신 구성요소 사용을 가리킴

모놀리식 커널과 Apple의 격리 강화 흐름

  • 현대 운영체제는 보통 사용자 모드와 커널 모드라는 두 보호 도메인으로 동작함
    • 애플리케이션은 파일 접근이나 네트워크 통신 같은 강한 권한 작업을 직접 수행하지 못하고 시스템 호출을 통해 커널에 요청함
    • 커널은 접근 권한을 확인한 뒤 열린 파일을 나타내는 핸들 같은 결과를 사용자 모드로 돌려줌
  • 대부분의 운영체제는 모놀리식 커널 구조를 사용하며, 커널은 하드웨어, 메모리, 사용자 데이터 전체에 제한 없는 접근 권한을 가짐
    • 커널이 커질수록 취약점이 생길 가능성도 커짐
    • 커널 취약점 악용은 전체 시스템 침해로 이어질 수 있음
  • 마이크로커널은 커널 내부 기능을 줄이고 대부분의 작업을 별도 비특권 프로세스로 밀어내 보안 격리를 개선할 수 있음
    • 성능 문제와 애플리케이션 소프트웨어 복잡도 증가는 단점으로 남음
  • iOS, macOS, tvOS, visionOS, watchOS가 공유하는 XNU는 Mach 마이크로커널 기반이지만, 구현상 여러 시스템 기능이 같은 특권 범위에 있어 사실상 모놀리식 커널처럼 동작함

Exclaves 이전의 Apple 보안 격리

  • 2013년 iPhone 5s에는 Secure Enclave가 도입됨
    • 전용 강화 CPU 코어에서 SepOS라는 마이크로커널 기반 OS가 실행됨
    • SepOS의 커널은 Apple의 L4-embedded 커스텀 버전인 cL4임
    • 암호화 키와 Face ID 같은 생체 정보 보호에 사용됨
    • iOS 커널이 침해돼도 Secure Enclave 자체를 겨냥한 추가 익스플로잇이 없으면 대체로 영향을 받지 않음
    • Secure Enclave와 Secure Exclaves는 서로 다른 대상임
  • 2017년 A11 기반 iPhone 8·iPhone X에서는 Page Protection Layer(PPL) 가 도입됨
    • 커널 일부에만 메모리 페이지 테이블 수정 권한을 주고, 나머지 커널은 직접 수정하지 못하게 함
    • 공격 표면이 작아 우회가 드물었지만, 나머지 커널은 여전히 데이터 침해에 필요한 많은 권한을 유지함
  • 2021~2023년 A15와 iOS 17에서는 Secure Page Table Monitor(SPTM) 가 PPL을 대체·개선함
    • 추가 메모리 기능을 보호하고 작은 커널 구성요소 단위로 격리함
    • Apple 서명 여부를 확인하는 코드 서명 검증도 분리됨
    • 이 시기 XNU 소스에 exclaves 간접 참조가 나타났고, 당시에는 SPTM이 관리하는 하위 시스템으로 추정됨

2024년 XNU Exclaves의 등장

  • M4·A18 기반 시스템을 지원하는 XNU 소스 공개로 Exclaves 구조 일부가 드러남
    • iPhone 16 같은 시스템이 대상임
    • 이전 프로세서에서는 Exclaves가 활성화되지 않음
  • Exclaves는 XNU에서 분리된 리소스를 가리키며, 커널이 침해돼도 보호되는 영역으로 설계됨
    • 리소스는 OS 빌드 시 미리 정의됨
    • 이름 또는 ID로 식별됨
    • 타입을 가지며 부팅 시 초기화됨
    • 고유한 도메인으로 구성됨
  • SPTM은 Exclave 전용 페이지 타입으로 Exclave 메모리를 XNU에서 보호함
  • 확인된 리소스 타입은 XNU와 Exclave 사이의 경계가 어디에 생기는지 보여줌
    • XNU와 Exclave가 함께 접근할 수 있는 공유 메모리 버퍼
      • XNU 입장에서 읽기 전용 또는 읽기·쓰기 가능으로 설정될 수 있음
    • 카메라·마이크 접근 표시기 같은 기능 보안에 쓰이는 오디오 버퍼와 센서
    • 여러 리소스를 자체 보안 도메인으로 묶는 Conclave와 Conclave Manager
    • XNU 스레드가 호출할 때 Exclave 공간에서 코드를 실행할 수 있는 서비스

Secure Kernel과 secure world

  • Exclave 서비스가 XNU에서 격리된 상태로 실행되도록 Apple은 Secure Kernel(SK) 을 도입함
  • SK 이미지 파일에는 “cL4” 버전 문자열이 포함됨
    • IPC 구조는 원래 SepOS cL4의 L4-embedded보다 seL4에 더 가까워 보임
    • SK 문자열에는 capability, frame, untyped memory, minting 같은 seL4 계열 용어가 자주 등장함
    • Apple은 2024년 4월 seL4 Foundation 가입을 공개함
  • SepOS가 전용 프로세서에서 실행되는 것과 달리, SK는 XNU/iOS와 같은 고속 애플리케이션 프로세서에서 실행됨
  • 이 구조에는 추가 프로세서 특권 레벨이 필요하며, 가능한 기반으로 가상화 확장, Apple의 SPTM 추가 기능, ARM TrustZone이 거론됨
    • XNU 소스에는 TrustZone의 secure world 전환 관련 참조가 있음
    • XNU와 iOS는 insecure world에서, SK는 secure world에서 동작하는 구조로 해석됨
  • SK는 Exclave, 리소스, 서비스에 제한된 운영 환경을 제공함
    • ARM이 제안한 Trusted Applications 설계 패턴과는 다름
    • Exclave 서비스와 Secure Kernel의 공격 표면이 제한적이어서, secure world에서 탈출해 XNU를 침해하는 일은 insecure world에서 XNU를 직접 공격하는 것보다 훨씬 어려울 가능성이 있음
  • XNU 소스에서 secure world 전환은 RINGGATE로 지칭됨
    • SPTM이 전환을 관리할 수 있다는 부분은 추정에 머물며, 관련 영역은 오픈소스가 아니라 바이너리 분석이 필요함

도메인, 리소스, Conclave

  • XNU는 부팅 중 발견한 Exclave 리소스 정보를 담기 위해 2단계 커널 테이블 구조를 초기화함
    • root_table은 이름으로 도메인을 식별함
    • 각 도메인은 해당 도메인의 리소스를 담는 2단계 테이블을 참조함
  • 확인된 도메인 구조는 다음과 같음
    • com.apple.kernel
      • Conclave launcher, 디버그 서비스, 보안 표시등용 ExclaveIndicatorController, 로그 서비스, ExclaveKit 부팅에 쓰이는 FrameMint 등을 포함함
      • Exclave 서비스가 upcall을 통해 XNU 공간에서 파일 I/O를 수행하는 데 쓰는 공유 메모리 버퍼 com.apple.storage.backend도 포함함
      • Conclave마다 하나씩 있는 Conclave Manager 리소스를 포함함
    • com.apple.darwin
      • 오픈소스 컴포넌트에서는 사용 사례가 없음
    • com.apple.conclave.name
      • Conclave마다 하나의 도메인이 존재함
      • 서비스, 오디오 버퍼, 공유 메모리 버퍼 등을 포함할 수 있음
    • com.apple.driver.*name*
      • 디바이스 드라이버별 도메인으로 주석에 근거해 존재가 언급되지만, 오픈소스 코드에서 실제 확인되지는 않음
  • Conclave는 여러 리소스를 담을 수 있는 리소스 타입이면서, 서비스와 리소스가 서로 공유 접근을 갖도록 하는 보안 단위임
    • Mach task는 호출 가능한 Conclave가 제한됨
    • 각 Conclave에는 커널 도메인에 위치한 Conclave Manager가 있음
    • Conclave는 attach, launch, stop, detach 같은 생명주기를 가짐
    • launching, stopping 같은 전환 상태도 존재함

Conclave 생성, 연결, 실행

  • XNU의 posix_spawn()은 task_add_conclave()를 호출해 task와 Conclave Manager 리소스를 연결할 수 있음
    • 관계는 1:1임
    • 하나의 task는 하나의 Conclave Manager에만 연결되고, 반대도 같음
  • Conclave를 spawn할 수 있는 주체는 launchd 또는 com.apple.private.exclaves.conclave-spawn entitlement를 가진 task임
    • com.apple.private.exclaves.conclave-host entitlement는 새 task를 spawn하기보다 자기 자신을 attach하는 권한에 가까운 것으로 해석됨
  • 커널은 대상 Conclave에 연결된 Conclave Manager 리소스를 com.apple.kernel 도메인에서 찾음
    • 이후 Conclave 리소스 구조체에 Conclave Manager endpoint로 향하는 Tightbeam endpoint를 저장함
    • Tightbeam은 Exclave 컴포넌트 간 통신을 위한 RPC 프레임워크로 보임
  • Conclave 실행은 연결된 Conclave Manager task에서 수행돼야 함
    • Exclaves가 EXCLAVES_BS_BOOTED_EXCLAVEKIT 상태까지 완전히 부팅될 때까지 launch 시도가 대기함
    • 새 Mach trap은 _exclaves_ctl_trap() 함수로 들어오며, EXCLAVES_CTL_OP_LAUNCH_CONCLAVE가 Conclave 실행에 사용됨
    • production 환경에서는 launch된 Conclave host가 tainted 상태가 될 수 있고, 이후 exit()가 커널 패닉을 일으킬 수 있음

Exclaves용 새 Mach trap

  • _exclaves_ctl_trap()은 Exclave 기능을 처리하는 새 Mach trap임
    • operation 파라미터에 따라 여러 동작을 수행함
    • 일반적으로 호출된 operation에 필요한 entitlement를 검증함
  • EXCLAVES_CTL_OP_BOOT는 시스템 부팅 중 두 번 호출됨
    • Exclaves boot stage 2 시작
    • ExclaveKit 부팅
    • 호출자는 launchd이거나 com.apple.private.exclaves.boot entitlement를 가져야 함
  • 나머지 주요 operation은 최소한 현재 task가 com.apple.private.exclaves.kernel-domain entitlement를 갖거나 관련 Conclave Manager task여야 함
    • EXCLAVES_CTL_OP_LOOKUP_SERVICES: 현재 task의 Exclave 도메인에서 서비스를 찾고, 실패하면 권한에 따라 Darwin 도메인과 kernel 도메인을 확인함
    • EXCLAVES_CTL_OP_ENDPOINT_CALL: 현재 task 도메인의 Exclave 서비스 endpoint를 호출해 현재 스레드가 secure world로 전환되고 특정 코드를 실행함
    • named buffer 생성과 copyin/copyout
    • audio buffer 생성과 copyout
    • sensor 생성, start, stop, status
    • notification resource lookup

Downcall과 Upcall

  • Downcall은 secure world에 있는 Exclave 서비스 endpoint 호출이며, secure world 코드 실행이 시작되는 지점임
  • Downcall은 현재 스레드를 secure world로 전환하고 secure 코드의 entry point에서 실행을 시작함
    • 다른 스레드에 작업을 맡기는 방식이 아님
    • 호출 task는 kernel domain entitlement를 갖거나 해당 서비스 Conclave에 연결된 Conclave Manager task여야 함
    • Conclave는 호출 가능한 서비스를 최대 128개까지 가짐
  • XNU는 sk_enter()를 통해 스레드를 Secure Kernel로 스케줄링하는 것으로 보임
    • SK가 독립 스레드를 갖지 않고, XNU가 secure world의 모든 스레드 스케줄링을 처리할 가능성이 있음
    • secure world에서 실행 중인 스레드는 yield, wait, suspend, interrupt 같은 일반 스케줄러 동작을 할 수 있음
    • 이 경우 스레드는 secure world를 떠나 XNU 커널 컨텍스트로 돌아오고, 이후 Exclave 스케줄링 코드로 다시 secure world에 스케줄링됨
  • Downcall의 IPC 구조는 secure world 진입 전에 request·response 버퍼로 설정됨
    • 최종 IPC request 구조를 준비하고 sk_enter()를 호출하는 동안 인터럽트와 선점이 비활성화됨
    • 이 구조가 CPU 코어마다 하나씩만 있기 때문임
    • Downcall response는 중단, upcall, yield, 재스케줄링 때문에 다른 CPU의 per-core response buffer로 돌아올 수 있음
  • Upcall은 secure world에서 실행 중인 스레드가 XNU의 도움이 필요할 때 Tightbeam을 통해 Exclaves upcall handler를 호출하는 방식임
    • 허용된 특정 XNU 함수로 제한됨
    • upcall 중인 스레드는 사용자 모드로 돌아갈 수 없음
    • secure world로 다시 downcall해 재진입하는 것도 허용되지 않음
    • 스레드는 upcall을 수행한 지점의 secure world 컨텍스트로 되돌아가야 함
  • 소스에서 확인된 upcall 범주는 메모리, 파일 저장소, DriverKit, DriverKit Apple Neural Engine, Conclave 제어임

XNUProxy와 부팅 단계

  • XNUProxy에 대한 참조는 많지만 정확한 위치와 역할은 확정되지 않음
    • 독립 Exclave 도메인일 수 있음
    • com.apple.kernel 도메인에서 특정 downcall을 처리하는 서비스 또는 서비스 묶음일 수 있음
    • secure world로 downcall을 수행하는 SPTM 하위 시스템일 가능성도 있음
  • Exclaves_L4.h 주석은 XNU Proxy가 여러 Exclave를 reachable하게 만든다고 적고 있음
    • user app 템플릿
    • audio driver
    • ExclaveDriverKit
    • Always On Processor와 Display Coprocessor용 SecureRTBuddy
    • Conclave control, Conclave debug 등
  • Exclaves 부팅은 insecure world와 secure world 사이의 조율을 필요로 하며, 문제가 생기면 보통 panic()으로 이어짐
  • 부팅은 세 단계로 나뉨
    • Stage 1은 오픈소스에서 보이지 않으며, SK를 메모리에 로드하고 코드 서명을 검증한 뒤 실행 가능하게 만드는 secure boot 과정일 가능성이 있음
    • Stage 2는 upcall server 초기화, secure kernel 부팅 정보 수집, Exclave scheduler 초기화, XrtHostedXNU kext 초기화, multicore 초기화, XNU Proxy 초기화, static Exclave resource 발견, Conclave Manager endpoint 생성 등을 수행함
    • Stage 3은 com.apple.service.FrameMint 서비스를 찾고 framemint_framemint__init(), framemint_framemint_populate() 관련 호출을 수행한 뒤 EXCLAVES_BS_BOOTED_EXCLAVEKIT 상태가 됨

SPTM 메모리 타입과 남은 한계

  • SPTM은 하위 시스템별 접근 제어를 위해 메모리 페이지에 타입을 지정함
    • 기존 타입에는 XNU_USER_EXEC, XNU_USER_DEBUG, XNU_USER_JIT, XNU_ROZONE, XNU_KERNEL_RESTRICTED, TXM·DART 관련 타입 등이 있음
  • Exclaves는 새 SK 관련 타입을 추가함
    • SK_DEFAULT: SK 전용, XNU 접근 불가
    • SK_IO: SK 전용, XNU 접근 불가
    • SK_SHARED_RO: SK와 XNU가 공유하지만 XNU는 읽기 전용
    • SK_SHARED_RW: SK와 XNU가 공유하며 XNU는 읽기·쓰기 가능
  • Exclaves는 Apple 운영체제에 defence in depth를 추가하기 위한 큰 투자로 볼 수 있음
    • 민감한 리소스를 격리해 잠재 공격 표면을 줄임
    • 단일 커널 침해의 영향을 낮추는 방향임
  • 실제로 어떤 구성요소가 커널에서 Exclaves로 이동하는지는 직접 분석되지 않음
    • 빌드 이미지는 보안 카메라·마이크 표시기, Apple Neural Engine 일부 기능, 일부 디바이스 드라이버, Secure Enclave와 통신하는 구성요소 사용을 가리킴
    • 향후 더 많은 구성요소가 Exclaves로 이동할 수 있음
    • Exclaves 바깥의 XNU 영역은 여전히 공격 대상임
  • 분석은 Apple Open Source XNU build 11215에 기반함
    • ExclaveKit, ExclaveDriverKit, XNUProxy의 정확한 위치, XNU의 secure world 전환 방식, Secure Kernel, secure world userspace는 추가 분석이 필요한 영역으로 남아 있음

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • 최근 Apple의 휴대폰·노트북 SoC에는 중첩 가상화 하드웨어 지원이 들어가며, 카메라 LED에 exclave를 쓰는 M4 iPad Pro도 포함됨
    다음 Apple Platform Security 가이드 개정판에서 SK exclave와 Wi‑Fi 레이더 감지를 위한 베이스밴드 완화책을 다뤄주길 기대함: https://help.apple.com/pdf/security/en_US/apple-platform-sec...
    Apple의 SPTM 추가 기능에 대해서는 SPTM 역공학 글도 있음: https://www.df-f.com/blog/sptm3
    XNU는 마이크로커널에서 영감을 받은 구조로 리팩터링 중이고, 코드 기반을 줄이면서 보안 민감 작업을 밖으로 옮기려는 방향임. 메모리 공간 격리는 Secure Page Table Monitor(SPTM)가 돕고, 코드 서명·권한 검증·Developer Mode·Restricted Execution Mode 같은 작업은 Trusted eXecution Monitor(TXM)가 맡음
    TrustZone 관련 CVE는 150개가 넘음: https://www.cve.org/CVERecord/SearchResults?query=trustzone
    Google도 몇 년 전 Pixel에서 하드웨어 중첩 가상화를 쓰는 pKVM을 구현했고, pKVM L0에 비해 TrustZone 권한을 협력적으로 낮추는 코드까지 Linux 메인라인에 올렸음. 다만 Debian “Linux Terminal” VM 외에는 pKVM/AVF를 활용한 방어 기능을 발표하지는 않았음

    • TrustZone CVE 대부분은 제조사가 TrustZone 보호 환경에 넣은 취약한 소프트웨어와 관련된 것임. 그런 소프트웨어 중에는 형편없는 것도 많고, 하드웨어 자체 취약점 보고는 매우 적음
    • 작성자가 후속 글과 수정된 다이어그램을 올렸음: https://randomaugustine.medium.com/more-speculation-on-excla...
      처음에는 TrustZone 사용을 추측했지만, exclave는 기존 SPTM과 GXF(Guarded Execution) 권한 수준을 쓸 수도 있어 보임. 그렇다면 RAM 요구사항과 개발 노력만 제외하면 iPhone 13 이상에서도 지원하지 못할 근본적 이유는 없을 수 있음. 물론 Apple에게도 엄청난 작업임은 분명함

  • Steve는 진심으로 “노트북은 개인의 일기장”이고, Apple에는 그걸 지킬 책임이 있다고 믿었던 것 같음
    Tim도 Steve와 같은 믿음이 없었다면 CEO가 되지 못했을 것 같음. 이상하게 들리지만 Steve가 정말 그리움
    https://www.youtube.com/watch?v=Ij-jlF98SzA

    • 산업·과학 장비를 만드는 입장에서는 Apple의 소비자 지향 기기가 완전히 쓸모없음. 충분히 유능한 컴퓨팅 장치를 이렇게 잠가버리는 것은 낭비처럼 보임
      기기 소유자가 바뀐 뒤에도 Apple이 장치와 소프트웨어 시장을 통제하는 방식도 마음에 들지 않음. 이런 생태계는 철저히 피하고 있고, 왜 많은 이른바 “해커”들이 보닛을 용접해 닫아버린 시스템에 열광하는지 모르겠음
    • Jobs는 분열적이었고 자주 까칠했는데, 애초에 왜 기술 억만장자를 그리워해야 하나 싶기도 함. 그래도 Mac, iPod, iPad 같은 좋아하는 제품을 만드는 데 기여한 Jobs와 Apple 사람들에게 빚진 느낌이 있음
      Jobs가 했던 말 중 아직도 와닿는 것들이 많음. 최근 Apple이 “classic Mac” 화면 보호기를 내놨는데, 원래 Mac GUI가 얼마나 세심하게 설계됐는지 보여줌. 앱 버그가 운영체제를 죽이던 시절을 그리워하는 사람은 없겠지만, Apple이 지금도 그때만큼 디테일에 집착했으면 좋겠음
    • Jobs를 향한 진심 어린 감정을 보면, 사람들이 LLM을 쓰고 경험할 때 비슷한 무언가가 작동하는지 궁금해짐
      조금 노골적으로 말하면, 거기에는 신비적이거나 종교적인 요소가 있는 듯함. 기적, 신탁, 아름다운 제품과 의식, 매끈하고 풍요롭고 영원한 미래를 제공해줄 신 같은 자상한 남자를 간절히 바라는 것처럼 느껴짐. 일종의 영적 “구멍”이 채워지는 느낌임
      Jobs나 LLM에 호감을 느끼는 사람을 깎아내리려는 뜻은 아니고, 그냥 관찰한 바를 공유하는 것임
    • exclave 글이 Steve에 대한 생각을 떠올리게 한 건 알겠지만, 어떻게 하나가 다른 하나로 이어졌는지는 잘 모르겠음. 설명해줄 수 있는지 궁금함

  • 관련 스레드: “Apple rearranged its XNU kernel with exclaves” https://news.ycombinator.com/item?id=43314171

    • 그 글의 요약을 보면 exclave는 메인 커널인 XNU에서 분리된 특정 리소스를 뜻하며, 커널이 침해돼도 접근할 수 없다고 설명함
      또 macOS 중간 릴리스에 다음 메이저 버전을 준비하는 기능이 들어가는 일은 드물지 않은데, Sonoma 14.4와 iOS 17.4, iPadOS 17.4, watchOS 10.4에 추가된 가장 근본적이고 중요한 기능이 exclave일 수 있다고 함
      https://eclecticlight.co/2024/08/20/sonomas-unfinished-busin...

  • 물리 카메라 LED 제어에 보안 exclave를 쓰는 건 꽤 놀랍고, 단순한 일을 위해 과도하게 복잡한 설계를 한 것처럼 보임
    카메라 모듈에 아주 작은 전용 하드웨어 로직을 넣는 것만으로도 충분했을 것 같음. 디지털 입출력이나 카메라 전원을 게이트하고, 카메라 로직을 빠르게 켰다 껐다 하는 공격을 막기 위해 LED가 매번 최소 몇 초 켜지도록 펄스 스트레처를 두면 됨
    마이크에도 비슷한 회로와 별도 색상의 물리 LED를 두는 게 좋겠음. 화면에 소프트웨어로 표시되는 점만으로는 부족함

    • 생각보다 복잡함. “카메라”는 여러 부품의 묶음임. CMOS 센서 전원을 기준으로 삼고 싶겠지만, 대기·절전·유휴 같은 여러 전력 단계가 있음. 그래서 하드웨어 회로는 전압뿐 아니라 전류도 알아야 할 가능성이 큼. 아니면 더 상위에서 I2C 같은 메시지를 파싱해 전원 모드 변경을 읽어야 할 수도 있음
      LED 구동부도 화면 밝기나 주변광 센서 정보를 알아야 함. 직사광선 아래에서도 보일 만큼 밝아야 하지만, 그 밝기는 어두운 환경에서는 불쾌하고 정상적인 카메라 사용을 방해할 수도 있음
      SK가 안전하다고 믿는다면, 그걸 쓰는 편이 더 단순하면서도 더 잘할 수 있음. SK가 안전하지 않다고 보면 어차피 모든 전제가 무너짐
    • 과도한 설계가 아님. 이런 연구와 Charlie Miller 같은 다른 연구자들의 결과 때문에 필요한 것임
      Apple은 대체로 정당한 이유 없이 일부러 복잡하게 만들지는 않음
      https://news.ycombinator.com/item?id=42260379
    • 과도한 설계인지, 아니면 엄청나게 많은 휴대폰을 출하하면서 발견한 무언가에 대한 해결책인지 궁금함. 카메라를 보안 벡터로 생각하지는 않았지만, Apple은 그렇게 보는지도 모름
    • 관련 배경은 여기에 더 자세히 있음: https://news.ycombinator.com/item?id=42260379
    • 카메라 LED만이 아니라, 앱이 마이크·카메라·화면 녹화에 접근할 때 메뉴 막대에 뜨는 주황색·녹색·파란색 점 같은 화면 표시기도 관련된 것 같음

  • 이 글쓴이가 누구인지 궁금함. 매우 정교하고 잘 쓴 글이고, exclave를 따라가던 입장에서도 잘 정리돼 있음

  • 이것이 Linux의 Virtualization Based Security와 어떻게 비교되는지 궁금함
    영상이 있는 페이지에 따르면, 이 보안 기능은 커널을 강화하고 커널이 침해돼도 중요한 커널 리소스가 변조되지 않게 보장할 수 있음. VBS는 하드웨어 가상화와 하이퍼바이저인 Hyper‑V를 사용해 더 높은 신뢰 수준인 Virtual Trust Level 1(VTL1)에서 동작하는 격리 가상 환경을 만들고, VTL1은 Guest 커널과 분리된 자체 커널인 Secure Kernel을 가짐
    https://lssna24.sched.com/event/1aIeD/linux-virtualization-b...

    • Exclave는 병렬적인 신뢰 수준에서 실행됨

  • Exclave는 중요하지만 중간 단계로 보임. Apple은 XNU가 리스크가 덜 되도록 만들고 있지만, 마이크로커널 구조를 완전히 받아들이기보다는 아직 방어적으로 움직이는 중임
    내기를 해야 한다면 exclave는 더 큰 변화로 가는 다리일 것 같음. Fuchsia 같은 더 모듈화된 운영체제일 수도 있고, 메모리 안전성을 하드웨어 수준에서 강제하는 CHERI식 보안 모델일 수도 있음
    Apple은 소비자용 운영체제 보안에서 앞서가고 있지만, exclave는 시스템 설계를 완전히 다시 생각한 결과라기보다 패치워크식 개선에 가까움. 그래도 지난 10년간 주류 운영체제 설계에서 가장 큰 보안 변화일 가능성이 높고, 전체 영향이 드러나기까지는 몇 년이 걸릴 것임

    • 예전의 마이크로커널로 돌아가는 방식으로 보임. 다만 현대적인 해법과 새로운 요구사항을 반영한 형태임
      Mach가 만들어졌을 때는 보안이 지금만큼 큰 관심사가 아니었음. 지금 기계들의 성능이 워낙 좋아져서, 마이크로커널 프로세스 간 통신이 만드는 오버헤드는 무시할 만해졌을 수도 있음

  • 이 수준의 내용에는 익숙하지 않지만, 보기에는 enclave 자체를 공격해서 커널보다 더 높은 권한으로 상승할 수 있는 것처럼 보임. 이 하드웨어 조각이 보조 프로세서 같은 것인지 궁금함

    • Exclave는 하드웨어가 아니라, 커널이 접근하지 못하게 하고 싶은 특정 민감 작업을 처리하는 격리된 소프트웨어임
      그래서 이를 익스플로잇하면 커널에는 없는 접근 권한을 얻는 것이 맞음. 하지만 바로 그게 의도임. 목표는 커널이 뚫리더라도 그 민감한 영역에는 접근하지 못하게 하는 것임

  • Apple 문서에 따르면 SPTM이 사용되지 않는다고 되어 있어, 이것이 macOS 보안에 어떤 영향을 줄지 궁금함: https://support.apple.com/guide/security/operating-system-in...
    지금으로서는 카메라 표시기를 띄우는 기존 exclave 같은 것은 MacBook에 전용 하드웨어가 있으니 macOS에는 크게 적용되지 않을 것 같음. 하지만 앞으로는 macOS에도 적용되는 exclave가 생길 수 있음

    • 그 각주를 다시 읽어봐야 함. Page Protection Layer(PPL)와 Secure Page Table Monitor(SPTM)는 macOS를 제외한 모든 플랫폼에서 서명되고 신뢰된 코드 실행을 강제한다고 되어 있음. macOS는 임의 코드를 실행하도록 설계됐기 때문임. 페이지 테이블 보호를 포함한 다른 보안 속성은 지원되는 모든 플랫폼에 존재함
      즉 macOS가 SPTM을 쓰지 않는다는 뜻이 아님. macOS가 서명되지 않은 코드 실행을 막는 용도로 SPTM을 쓰지 않는다는 뜻임. macOS는 사용자가 몇 단계를 거치면 서명되지 않은 코드도 실행할 수 있어야 하기 때문임

  • 앱 개발자가 Exclave를 사용할 수 있는지 궁금함. Apple은 내부적으로 놀라운 새 기능을 만들고는 개발자에게는 완전히 막아두는 경우가 불만임. 그 결과 은행 앱, 지갑, 보안 메신저 같은 것들은 계속 보안이 약한 사용자 공간에서 돌아가야 함

    • 꼭 그렇지는 않음. Apple의 사용자 공간도 계속 더 안전해져 왔음
      간단한 예로, 최근 macOS는 앱이 명시적으로 선택하지 않아도 모든 앱을 샌드박스 안에서 실행함. 이 샌드박스는 앱들이 서로의 파일을 수정하는 것을 막는데, 이전에는 이 부분이 보안 시스템의 큰 약점이었음. 번들 서명은 최초 실행 때만 확인되고 매 실행마다 확인되지는 않았기 때문임
    • 현재 설계로는 안 되는 것으로 이해함. Exclave는 전체 운영체제에 통합되어 있고 부팅 과정의 일부로 시작되므로 비교적 정적임. 보안상 이유로 이 구성요소들의 관계도 정적으로 잡혀 있을 가능성이 큼
      지금은 커널 대 커널 구조이기도 해서, 서드파티 지원이 있다면 보안 장치 드라이버 같은 것을 구현하는 정도로 제한될 가능성이 높음. 하지만 Apple은 서드파티 드라이버를 하이퍼바이저가 아니라 사용자 공간으로 밀어내려 해왔음. 이 전환이 exclave 개발과 병행되는 점을 보면, 서드파티 드라이버 개발자가 exclave를 쓰게 하려는 방향으로 전환할 것 같지는 않음
      Apple이 이런 커널 강제 플랫폼 기능을 외부에 공개하기 전에 내부에서 훨씬 더 안정화하는 일은 흔함. arm64e의 포인터 인증도 비슷한 예임
    • 현재는 안 됨
답변달기