애플 실리콘에 리눅스를 이식하는 프로젝트 아사히 리눅스(Asahi Linux)의 한 개발자가 2024년 11월 구매한 M4 맥 미니에 리눅스를 처음으로 부팅시키기까지의 과정을 블로그에 상세히 공개했다. M1부터 M3까지는 비교적 수월하게 지원됐던 반면, M4는 애플이 처음으로 도입한 강화된 보안 체계 때문에 훨씬 까다로운 작업이었다. 단순한 성공 후기가 아니라, 최신 실리콘에서 운영체제를 밑바닥부터 띄우는 과정이 실제로 얼마나 지난한 디버깅의 연속인지를 보여주는 기록이라는 점에서 눈여겨볼 만하다.

M4가 까다로웠던 이유, SPTM이라는 새로운 벽

아사히 리눅스는 그동안 m1n1이라는 하이퍼바이저를 이용해 macOS의 XNU 커널이 하드웨어와 주고받는 MMIO(메모리 매핑 입출력) 트래픽을 그대로 기록하고 분석하는 방식으로 작업을 진행해왔다. macOS 드라이버가 실제로 어떤 순서로 레지스터를 건드리는지 엿보면서 리눅스용 드라이버를 거꾸로 만들어내는 식이다.

그런데 M4부터는 애플이 SPTM(Secure Page Table Monitor)을 의무적으로 탑재하기 시작했다. SPTM은 XNU 커널의 취약점을 악용한 공격을 막기 위한 하드웨어 수준의 보호 장치로, macOS를 하이퍼바이저 아래에서 돌리려면 m1n1 자체에 대규모 수정이 필요해졌다. 원문 작성자는 이 작업이 “신참인 자신이 감당하기엔 벗어나는 수준”이라고 밝힐 정도로 난이도가 높았다고 설명한다.

GXF 비활성화와 RVBAR, 뜻밖의 복병들

하이퍼바이저를 통한 정공법이 막히자, 작성자는 macOS 복구 모드를 이용해 부팅 보안을 해제하고 m1n1을 커스텀 부트 오브젝트로 설치한 뒤, 시리얼 콘솔로 로그를 들여다보는 우회 경로를 택했다. 처음에는 m1n1이 BRINGUP 모드에서만 겨우 시작됐고, 정상 모드로 올리려 하면 GXF(Guarded Execution Framework) 초기화 과정에서 바로 크래시가 발생했다. 알고 보니 M4 이상 SoC에서는 일반 부팅 모드에서 GXF 기능 자체가 잠겨 있어, 해당 초기화 코드를 조건부로 건너뛰도록 고치는 것이 해법이었다.

또 다른 복병은 RVBAR(Reset Vector Base Address Register)였다. 이는 CPU 코어별로 전원이 켜질 때 어디서부터 실행을 시작할지 정하는 레지스터인데, 기존 방식대로 이 값을 새로 써넣으려 하면 크래시가 발생했다. 확인해보니 이미 올바른 값이 들어있었던 것으로 밝혀져, 해당 쓰기 작업 자체를 생략하는 것으로 해결됐다. 겉보기엔 사소한 레지스터 두 개지만, 이런 차이 하나하나가 새 SoC 세대마다 리버스 엔지니어링을 처음부터 다시 해야 하는 이유를 보여준다.

println 디버깅으로 찾아낸 MMU 매핑 누락

이후 한동안 작업이 중단됐다가, 2025년 말 카오스 컴퓨터 콩그레스(CCC) 행사를 계기로 다시 동력을 얻었다. CPU 코어와 인터럽트 컨트롤러만 담은 최소한의 디바이스 트리를 직접 만들고, m1n1의 linux.py로 커널을 로드했지만 “Vectoring to next stage” 메시지 이후로는 아무 출력도 나오지 않았다.

단서가 없던 작성자는 가장 원초적인 방법, 즉 println 디버깅을 택했다. m1n1의 debug_putc 어셈블리 루틴을 떼어와 알파벳 ‘a’ 하나를 출력하도록 고친 뒤, 리눅스 커널의 아주 초기 부팅 코드 곳곳에 심어가며 어디까지 실행되는지 이분 탐색하듯 추적했다. 그 결과 문제는 arch/arm64/kernel/head.S에 있는 MMU 초기화 코드 근처였다.

원인은 MMU 자체가 아니라 메모리 매핑 누락이었다. UART(시리얼 출력)는 MMIO로 접근하는데, MMU가 켜지면 모든 메모리 접근이 가상 주소를 거쳐 페이지 테이블로 물리 주소에 매핑된다. m1n1은 MMIO 주소 공간을 가상 주소와 동일하게 매핑해두지만, 리눅스 커널은 이런 매핑을 기본으로 만들어두지 않는다. 결국 MMU가 켜지는 순간 UART 대신 매핑되지 않은 빈 공간에 접근하게 되어 출력이 끊겼던 것이다. 초기 페이지 테이블에 MMIO 영역에 대한 1:1 매핑을 직접 추가하자, 디버그 출력이 훨씬 더 앞으로 나아갔다.

왜 이 과정이 의미 있는가

이 작업은 단순히 “리눅스가 M4에서 돌아간다”는 결과보다, 그 결과에 도달하기까지의 방법론이 더 값지다. 공개 문서나 소스가 전혀 없는 상태에서, 하드웨어 트레이스 분석과 바이너리 레벨 디버깅만으로 부트로더부터 커널 초기화까지 한 단계씩 원인을 좁혀나가는 과정은 리버스 엔지니어링과 저수준 시스템 프로그래밍을 공부하는 개발자에게 좋은 참고 사례가 된다.

한국에서도 애플 실리콘 맥에 리눅스를 설치해 쓰는 개발자들이 꾸준히 있는 만큼, 이번 M4 지원 작업이 어느 정도 안정화되면 데스크톱 리눅스 환경에서 선택지가 넓어질 수 있다. 다만 원문에서 다룬 내용은 아직 부팅 초기 단계의 디버깅 성과이며, GPU나 전원 관리 등 본격적인 드라이버 지원까지는 추가 작업이 필요할 것으로 보인다. 아사히 리눅스 팀은 이런 작업을 후원금으로 지속하고 있으므로, 관심 있는 독자라면 Asahi Open Collective를 통한 후원도 고려해볼 만하다.

원문: The Forgetful CPU (Linux on M4)