요약
AI 에이전트 덕분에 유니커널을 만드는 수고가 줄었으니, 보안을 중시한다면 다시 검토할 때입니다.
개발자 제프리 헌틀리가 예전에 MirageOS 개발에 참여한 저스틴 코맥과 나눈 대화를 정리한 글입니다. 유니커널(애플리케이션과 운영체제를 하나로 묶어 셸이나 다른 프로세스 없이 돌리는 방식)은 네트워크와 저장소 기능까지 라이브러리로 직접 갖춰야 해서 쓰기 어려웠습니다.
왜 중요한가
- 유니커널을 막아 온 것은 부족한 라이브러리였고, 에이전트가 이를 메우는 비용을 크게 낮췄다는 주장입니다.
- 공격 표면(공격자가 노릴 수 있는 지점)을 조금씩 줄이던 관행 대신 운영체제 계층을 아예 없애자는 제안입니다.
핵심 내용
- 코맥은 에이전트로 mkfs.xfs를 러스트로 옮겨 몇 시간 만에 원본과 바이트 단위로 같은 결과를 얻었습니다.
- 원본 도구를 정답지로 삼아 출력을 비교하고 테스트를 옮겨 오면 이식이 쉬워진다고 했습니다.
- 헌틀리는 셸이 없으면 침입자가 다음 단계로 넘어갈 발판이 사라진다며, 셸을 유출을 돕는 "VIP 집사"에 빗댔습니다.
- 높은 보증이 필요한 곳은 seL4(수학적으로 검증된 마이크로커널)를, 나머지는 유니커널을 쓰자고 했습니다.
- 코맥은 컨테이너에도 인터프리터가 남고 메모리 안전 문제도 있어 공격 표면 논리는 모호하다고 반론했습니다.
HN 반응
- strace나 eBPF 같은 관찰 도구를 잃는다는 우려가 많았고, 하이퍼바이저가 크래시 덤프를 받으면 된다는 반론도 나왔습니다.
- 메모리가 손상되면 어차피 뚫린다는 회의론에, 한 유니커널 개발자는 여러 프로그램을 돌리는 운영체제 자체가 문제라고 반박했습니다.
이번 주에 올라온 유니커널 글이 이게 두 번째인 것 같은데, 이 글 역시 완전한 OS를 갖추는 것의 이점을 너무 깎아내립니다. 단어 몇 개만 바꿔 보겠습니다.
strace, eBPF,lsof,ss같은 도구는 엄청난 가치가 있습니다. 글에서도 관측성에 도움이 되는 좋은 것들("구조화된 로깅, OTel")을 언급하지만, 버려지는 것이 너무 많습니다.저는 임베디드 소프트웨어를 조금 다뤄 본 적이 있는데, 그 과정에서 Zephyr( http://www.zephyrproject.org )의 팬이 되었고, 이걸 유니커널로 쓰면 어떨지 궁금합니다.
장점부터 말하자면, 이건 유니커널입니다. 애플리케이션과 함께 컴파일하면 바이너리 하나가 나옵니다. 가상 하드웨어에서 실행하는 것도 지원하고( https://docs.zephyrproject.org/latest/hardware/virtualization/virtio.html ), virtio는 요즘 BIOS나 다름없죠?
단점은 Nginx 같은 "전통적인" 소프트웨어를 여기에 이식하는 일이 고통스러울 것 같다는 점입니다. 그리고 Alpine Linux 컨테이너 이미지가 꼭 빠르다고 할 수 없는 것처럼, 성능도 장담하지 못합니다.
그래도 툴체인, 디버깅 방법, 드라이버까지 전부 갖춰져 있고, 결과물은 아주 작은 데다 사실상 즉시 부팅됩니다. 어딘가에는 분명 쓸모가 있지 않겠습니까?
이제는 에이전트랑 컴퓨팅 자원만 충분하면 사실상 해결된 문제라고 봐요.
이런 글을 보니 반갑네요! 저는 제 BareMetal 커널을 기반으로 유니커널을 호스팅하는 클라우드 서비스를 제공하고 있어요.
램 4MiB에 디스크 없는 소형 네트워크 VM이 시간당 약 0.005 캐나다 달러예요.
https://baremetal.returninfinity.com
정말 오랜만에 보니 재밌네요. 저는 2013년쯤 대학생 때 baremetal을 처음 만져 봤습니다. 상위 프로토콜은 신경 쓸 필요 없이 이더넷 프레임만 쓰면 되는 네트워크 API로 작은 컴퓨터끼리 메시지를 주고받는 게 정말 즐거웠습니다.
지금도 같은 커널입니까?
기억해 주셔서 기뻐요! 저는 꽤 오랫동안 이 작업을 꾸준히 해 오고 있어요.
커널은 대체로 그대로이고, Firecracker 위에서 돌리기 위한 수정만 더했어요.
이 글에 전적으로 동의합니다. AI가 등장한 지금이야말로 유니커널이 아키텍처의 어디에 들어맞을지, 공격 표면을 최소화하는 데 어떻게 활용할 수 있을지 고민해 볼 최적의 시기라고 생각합니다.
저도 직접 살펴보기 시작했고, Firecracker 같은 성숙한 VMM과 비교하면서 스택의 각 부분을 어디에서 돌리는 게 가장 좋을지 따져 보고 있습니다.
AI가 끼어드는 상황에서는 가상 머신과 컨테이너가 더는 효과적인 격리 수단이 아닙니다. VM 탈출이 점점 쉬워지고 있습니다. 그러니 모두가 런타임에 더 나은 보안을 내장할 방법을 고민해야 합니다.
공격 표면 최소화를 진지하게 목표로 한다면 FOGA를 받아들여야 합니다. LLM이 짠 유니커널은 군더더기가 너무 많아요.
Zynq UltraScale+ 부품은 하드 ARM CPU와 FPGA 패브릭을 함께 제공합니다. 빠른 경로와 보안이 중요한 구성 요소를 로직으로 단계적으로 격리할 수 있어요. LLM도 합성 도구를 꽤 잘 쓰게 되고 있고요.
https://www.amd.com/en/products/system-on-modules/kria/k26/kv260-vision-starter-kit.html
그래도 제가 본 바로는 HDL 디버깅은 여전히 형편없이 못해요. 서로 얽힌 신호가 너무 많거든요. 블로킹/논블로킹 할당이나 스코프 같은 건 특히 어려워하고요. 아직 Opus 5.5로는 시도해 보지 못했지만요.
맞아요. 트레이스가 되는 실제 장치나 괜찮은 시뮬레이터를 루프에 넣어 줘야 해요. 큰 EDA 회사들이 도구 통합이나 전용 모델을 만들고 있을 테고, 참고할 설계 라이브러리도 방대할 거예요.
이 주제에서 전에도 나온 얘기입니다만, 디버깅 가능성은 어떻습니까? 이제 애플리케이션 오버플로가 네트워크 스택 일부를 망가뜨리게 됩니다.
Oxide 에피소드에서 데이터 라인을 읽어 내는 이야기가 조금 나왔지만, 그건 현실적이지 않다고 봅니다.
공격 표면이 줄어드는 건 멋진 일이지만, 시스템을 들여다볼 수 있는 가시성과 살아 있는 상태를 희생하면서까지 얻을 일은 아닙니다.
저도 이 때문에 유니커널이 보안에 얼마나 도움이 되는지 잘 모르겠습니다. 임의의 메모리를 오염시킬 수 있다면 임의의 기계어 코드를 실행할 수 있습니다. 유니커널이 무엇을 노출하는지는 상관이 없습니다.
이 질문은 늘 나오는데, 저는 현재 상태가 꽤 부실하다고 생각합니다. 저도 유니커널에 gdb 스텁을 붙여 본 적이 있지만, 결국 한 번도 쓰이지 않았으니 그게 정답은 아니었던 모양입니다.
사람들은 리눅스가 주는 훌륭한 디버깅 환경을 잃게 된다고 늘 말합니다. 그런데 큰 클라우드 환경에서 서비스가 죽으면 지금 뭘 하길래 그렇게 잘 돌아간다는 겁니까? 단일 프로세스 커널에 그걸 구현하는 게 도저히 불가능하다고 보십니까?
저한테 제일 큰 문제는 살아 있는 상태가 완전히 사라진다는 점, 적어도 사라질 수 있다는 점입니다. 일반적인 머신에서는 프로세스가 죽더라도 주변 기능을 이것저것 살펴볼 수는 있습니다. 불가능하다는 말이 아니라 어려운 문제인데 충분히 강조되지 않는다고 생각합니다.
이런 게 만들어졌는지는 모르겠지만, 유니커널 VM이 크래시할 때 하이퍼바이저가 스택 트레이스, 로그 버퍼, 코어 덤프를 캡처하게 할 수 있을 것 같습니다.
저는 보안 연구자는 아니지만, 적어도 지난 15년 동안 악성코드 실행을 단계별로 추적하는 데는 VM이 선호되는 도구였다고 알고 있습니다. 그걸 위한 IDA 확장 프로그램을 본 기억도 나고요.
네, 이런 용도로 관리형 런타임(MirageOS의 OCaml 같은 것, 아니면 Go나 JVM도 어울릴 수 있겠죠)을 쓰자는 논거가 보통 그겁니다. 포인터나 메모리 접근 같은 기본 요소가 아예 없고 가비지 컬렉션이 되는 VM을 "베어메탈"에서 바로 돌리면 그런 문제에 대해 훨씬 마음이 놓입니다.
메모리 안전성을 갖춘 Rust도 후보라고 주장할 수 있겠지만, Rust라도 거기서 벗어나는 것은 여전히 충분히 가능하고 꽤 쉽습니다. 게다가 Rust/Cargo 애플리케이션은 서드파티 의존성을 엄청나게 끌어다 쓰는 버릇이 있어서, 그걸 일일이 주시해야 하고요.
저는 타입 시스템에 모듈 수준의 안전성 속성이 있어서, unsafe가 사용자 코드가 부여하는 권한(capability)이 되어야 한다고 늘 생각해 왔습니다.
자연스러운 R&D 프로젝트라면 고빈도 OMS나 NYSE 매수/매도/체결 북 관리자 같은 걸 만들어 보는 것이겠습니다.
이런 앱들은 어차피 네트워크 I/O에 커널 바이패스를 쓰는 편이고, OMS에 필요 없는 인터럽트와 그 밖의 불필요한 지터를 최대한 없애려고 OS를 철저히 손봅니다.
다만 저수준 커널 바이패스 코드(예: DPDK, libfabric)는 하드웨어와 규율 있게 통신하는 데 리눅스에 의존한다고 알고 있습니다.
더 잘 아시는 분 계십니까?
이런 방식으로 OMS가 어느 정도 빨라진다면 그쪽 업계에서 가끔 보이는 FPGA의 현실적인 대안이 될 수 있을 겁니다. (물론 하드웨어는 같은 장소에 두어야겠지만요.)
저는 몇 년째 OCaml을 쓰고 있지만 Mirage는 아직 파 보지 못했어요. 정말 멋지네요. Yaron 일화도 좋았고요. OCaml로 바이브 코딩을 하면 초능력을 얻은 기분이에요. 거기에 Oxcaml까지 더해서 회사 전체가 그걸 쓴다면 기분이 정말 좋을 것 같아요.
공격 표면을 줄이는 건 분명 장점이지만, 유니커널을 돌릴 때 얻는 보안상 이점 가운데 가장 큰 것과는 거리가 멉니다.
그래서 저는 "공격 표면 축소"를 그렇게 많이 이야기하고 싶지 않았습니다. 사람들은 어쩔 수 없이 줄 수나 코드량으로 생각하게 되는데, 그걸 줄이는 것도 좋긴 하지만 정말 큰 문제가 무엇인지는 전혀 전달하지 못하기 때문입니다.
데이터 유출의 첫째 진입 경로는 취약점 악용이고, 작년 CISA KEV에서 가장 많았던 CWE는 OS 명령 주입입니다.
작년 DBIR에서는 "시스템 침입"이 64번쯤 반복해서 나왔습니다.
운영체제 자체가 문제입니다. 본래 여러 가지 프로그램을 돌리라고 만든 것인 반면, 유니커널은 하나만 돌리니까요.
구획화를 통한 보안에 의존한다면 얘기가 다릅니다. 다음을 보세요: https://qubes-os.org
솔직히 유니커널(적어도 제가 활동하는 쪽)과 Qubes는 비슷한 점이 많다고 생각합니다. 제가 보기에 가장 큰 차이는 Qubes가 데스크톱/일반 소비자 쪽에 더 맞춰져 있고, nanos(제가 참여하는 쪽)는 서버 쪽에 더 맞춰져 있다는 것입니다. 하지만 같은 종류의 이념과 원칙이 드러나는데, 다만 수준이 다르고 최종 환경이 다르니 설계가 다르게 될 뿐입니다.
당신이 거짓말을 하지 않은 건 seL4를 언급할 때뿐이에요.
지금 타넨바움에게 맞서는 리누스 꼴이에요. 이겨도 결국 지는 거죠.
죄송한데 무슨 말씀이세요? 쉽게 좀 설명해 주실 수 있나요?
저는 이쪽을 전혀 모르니 요점을 놓치고 있을 가능성이 크지만, OS의 존재 이유가 파일시스템과 네트워킹을 필요할 때마다 (바이브) 코딩으로 직접 만들지 않아도 되게 하는 것 아닙니까? 그리고 유니커널은 다른 애플리케이션과 어떻게 협력합니까? 전부 하이퍼바이저가 관리하는 각각의 네트워크로 연결된 유니커널에서 돌아가게 됩니까? 또 다들 자기 파일시스템과 네트워크를 (바이브) 코딩으로 만들면 미묘한 버그와 불일치가 생겨서 결국 전체가 무너지고, 처음부터 공유되는 기본 요소가 필요했다는 결론으로 돌아오지 않겠습니까?
그렇다면 유니커널은 두되, 네트워킹이나 파일시스템 같은 공통 기능의 라이브러리는 표준에 따라 이미 만들어져 있어서 꽂아 쓰기만 하면 되고 여러 애플리케이션에서 재사용할 수 있게 하는 것이 좋은 절충점일지도 모르겠습니다.
유니커널은 추상화의 경계를 다시 그을 뿐입니다. 공통 기본 요소를 구현하는 데 여전히 라이브러리와 서드파티 코드를 쓸 수 있습니다. 실제로 많은 유니커널 프레임워크(unikraft, hermit, mirage)가 정확히 그걸 제공합니다.
그 추상화 경계는 가상 메모리와 시스템 콜 인터페이스로 보호됩니까? 그래서 프로그램의 하위 모듈이 다른 모듈에 속한 메모리를 망가뜨릴 수 없습니까? 다른 쪽에 영향을 주지 않고 하위 작업만 재시작할 수 있습니까? 전통적인 OS는 비교적 적은 오버헤드로 그 모든 걸 제공합니다.
케이퍼빌리티 기반 마이크로커널에서는 소유권과 자원을 아주 세밀한 수준까지 할당할 수 있어서, 크래시에 대한 견고함과 핵심 시스템 정책을 노리는 공격에 대한 방어력이 높아집니다. 유니커널도 그 모든 걸 제공할 수는 있겠지만, 그러면 마이크로커널보다 오히려 프로그래밍하기 불편해질 것 같습니다.
그래서 전체적으로 저는 유니커널의 장점을 모르겠습니다. 제 생각에 더 올바른 프로그램을 쓰는 데 도움이 되지도 않고, 성능 향상도 제한적입니다.
다른 분들이 이미 같은 얘기를 했을 것 같지만, 유니커널은 가상 하드웨어가 있는 VM에서 돌아가니까 가상 이더넷 카드는 프로그래밍하기 쉬운 인터페이스를 가질 수 있고, 그러면 드라이버가 간단해지겠죠. 어차피 실제 하드웨어와 통신하는 게 아니니까요.
마찬가지로 파일시스템은 우연히 디스크 위에 있는 자료구조일 뿐입니다. 하드디스크를 mmap해 두고 스왑이나 선점 같은 건 호스트 하이퍼바이저에게 맡기면 됩니다.
프로세스 계약과 비슷하지만 경계가 조금 다릅니다.
저는 이 부분이 이해가 안 됩니다. 결국 그 N개의 유니커널을 아래에 하이퍼바이저를 둔 VM에서 돌리게 될 텐데, 전통적인 커널을 쓰는 잠금 처리된 OS에서 정적 바이너리를 돌리는 것과 뭐가 다릅니까? 글에서 말하듯 "kvm을 터뜨려서" 유니커널을 탈출할 수도 있을 텐데, 그게 어떻게 더 안전합니까? 원리상 같은 걸 돌리면서 이름만 다르게 부르는 것 아닙니까(앱은 유니커널+앱이 되고, 커널은 하이퍼바이저가 되는 식으로요).