애플 실리콘용 리눅스를 만드는 Asahi Linux 프로젝트가 리눅스 7.2 릴리스에 맞춰 새로운 진행 보고서를 내놓았다. 이번 보고서의 핵심은 배터리 수명과 직결되는 CPU 전력 관리, M4 이상 기기에서 하이퍼바이저를 되살린 SPTM 우회, 그리고 M3 계열 하드웨어 지원 확대다. 각각은 애플이 공개하지 않는 하드웨어를 역공학으로 뜯어내며 표준 리눅스 커널과 타협점을 찾아가는 과정을 잘 보여준다.
CPU를 재우는 표준과 애플의 예외
ARM 코어를 잠재우는 가장 기본적인 방법은 WFI(Wait For Interrupt) 명령이다. 코어는 인터럽트가 올 때까지 코드 실행을 멈추지만 전원과 상태는 유지해 곧바로 깨어날 수 있다. 애플 코어에는 더 많은 부분을 끄는 대신 상태를 잃는 '딥 WFI' 모드가 있고, Asahi의 다운스트림 cpuidle 드라이버는 이 모드를 설정한 뒤 코어 상태를 저장하고 WFI 루프를 도는 방식으로 작동한다. 문제는 이런 벤더 고유의 방식이 커널 업스트림에서 환영받지 못한다는 점이다. arm64 아키텍처 메인테이너들은 전력 관리를 반드시 PSCI(Power State Coordination Interface) 표준으로 처리하도록 요구하고 있어, 애플 전용 cpuidle 드라이버는 원칙적으로 상류로 올릴 수 없다.
더 근본적인 걸림돌은 실행 계층 구조에 있다. PSCI는 SMC나 HVC 명령으로 상위 예외 계층(EL3)의 펌웨어에 호출을 넘기도록 설계됐는데, 리눅스는 EL2에서 돌고 EL3의 펌웨어가 이를 처리한다. 그런데 애플 코어는 아예 EL3를 구현하지 않는다. 넘겨줄 상위 계층이 없으니 표준 방식의 PSCI 호출 자체가 성립하지 않는 것이다.
m1n1을 펌웨어처럼 쓰는 우회로
Asahi 개발자들이 찾은 답은 부트로더 m1n1을 사실상 자체 펌웨어로 활용하는 것이다. 실제 Asahi 시스템에서 m1n1은 커널을 직접 띄우지 않고 U-Boot를 로드하며, 이는 U-Boot의 UEFI 구현을 통해 GRUB이나 systemd-boot 같은 표준 부트로더를 쓰기 위함이다. 여기서 UEFI가 제공하는 런타임 서비스가 실마리가 됐다. PSCI 표준이 SMC·HVC를 '예시'로만 들 뿐 특정 전달 경로에 묶어두지 않았다는 점에 착안해, Sven은 UEFI 런타임 서비스를 새로운 PSCI 전달 경로로 삼는 작업을 진행 중이다. m1n1이 다른 펌웨어처럼 자기 메모리 영역을 예약해 두고 PSCI 구현을 남겨두면, 커널이 같은 예외 계층에 있더라도 그 코드를 되불러 쓸 수 있다. 관련 커널 패치는 이미 RFC 형태로 메일링 리스트에 올라와 있다.
이 작업에 불을 붙인 것은 M4의 골치 아픈 변화다. 코어 상태 보존 여부를 조정하던 '치킨 비트'를 애플은 M4부터 mBoot 단계에서 설정하고 레지스터를 잠가 버렸다. 덕분에 m1n1의 일은 조금 줄었지만, M4에서 WFI를 호출하면 코어가 상태를 잃고 실행 중이던 것을 날려버린다. Yurkea는 M4 브링업 중 이를 발견하고, 커널이 유휴 루프에서 코어를 어떻게 주차할지를 명령줄 인자로 지정하도록 만들었다. cpuidle 드라이버가 뜨기 전 초기 부팅 단계에서 no-op 루프로 코어를 놀려 크래시를 막고, 이후 드라이버가 상태 저장을 넘겨받는 구조다. 이 패치는 이미 linux-next에 들어가 있다.
SPTM이 막았던 하이퍼바이저를 되살리다
애플의 보안 강화도 큰 장벽이었다. 페이지 테이블 관리를 커널 본체에서 하드웨어 수준으로 격리하던 PPL(Page Protection Layer)이 결국 뚫리자, 애플은 이를 SPTM(Secure Page Table Monitor)으로 발전시켰다. SPTM은 표준 EL1·EL2와 나란히 도는 GXF라는 별도 예외 계층과 SPRR 권한 체계 안에서 동작하며, XNU는 부팅 초기에 SPTM과 통신하지 못하면 곧바로 패닉을 낸다. M4 이상에서 SPTM이 필수가 되면서 macOS를 관찰하는 데 쓰던 m1n1 하이퍼바이저가 완전히 무력화됐고, 이는 새 하드웨어 역공학에 치명적이었다.
해법은 SPTM 자체의 평범함에서 나왔다. SPTM은 코프로세서 펌웨어들과 같은 디렉터리에 놓인 ARM64 Mach-O 바이너리일 뿐이다. Sven이 Asahi 초창기에 역공학해 둔 SPRR·GXF 지식을 활용해 하이퍼바이저가 이 둘을 에뮬레이션하도록 가르쳤고, 그 결과 애플의 SPTM 블롭을 XNU가 기대하는 방식대로 로드한 뒤 XNU 바이너리에 약간의 수술을 가해 나란히 감시할 수 있게 됐다. 이 방식은 추적 속도가 다소 느려지지만 쓸 수 없을 정도는 아니어서, 앞으로도 신규 하드웨어 브링업을 이어갈 수 있게 됐다.
M3 계열로 넓어지는 지원
M3 계열에서는 애플이 굳이 큰 아키텍처 변경을 하지 않으리라는 프로젝트의 가정이 대체로 맞아떨어졌다. 웹캠 ISP는 M3 Max에서 초기화 메시지 하나가 빠진 정도라 chaos_princess가 드라이버에 이를 반영해 내장 웹캠 지원을 마쳤고, 새로 추가된 '고주파' 데시메이터에 필요한 계수와 초기화 메시지도 정리해 내장 마이크를 살렸다. 다만 TSMC N3 공정 전환으로 USB3·DisplayPort·썬더볼트를 담당하는 ATCPHY의 초기화 튜너블이 바뀌었고, USB 포트 컨트롤러도 I2C 기반 CD3217(ACE2)에서 SPMI 버스를 쓰는 ACE3로 교체됐다. mildsunrise와 chaos_princess는 ACE3가 사실상 같은 레지스터 셋을 SPMI로 감싼 것임을 밝혀내 USB 3.0과 썬더볼트를 지원하게 했다.
실무자 입장에서 이 보고서가 주는 함의는 분명하다. 문서화되지 않은 폐쇄 플랫폼에 리눅스를 올리는 일은 결국 부트 체인의 구조적 제약을 이해하고, 표준 스펙의 여백을 파고들어 합법적 우회로를 만드는 협상의 연속이다. UEFI 런타임 서비스를 PSCI 경로로 재해석한 시도나 SPTM 에뮬레이션은 업스트림 정책과 하드웨어 현실 사이에서 타협점을 찾은 대표적 사례다. 다만 애플 전용 cpuidle 드라이버가 여전히 상류에 오르지 못하고, GPU·디스플레이 펌웨어가 특정 macOS 버전(M3의 경우 macOS 14.8.3)에 묶여 있는 한 세대마다 반복되는 대응 부담은 남는다. 표준화된 인터페이스가 없는 플랫폼을 다룰 때 감수해야 할 구조적 비용을 보여주는 대목이다.