▲

Asterinas - 새로운 Linux-호환 커널 프로젝트

 (lwn.net)
7P by GN⁺ 3일전 | ★ favorite | 댓글 2개
  • Rust로 작성된 Linux ABI 호환 커널로, “프레임커널(framekernel)” 아키텍처를 적용해 모놀리식과 마이크로커널의 장점을 결합하고자 함
  • 모든 unsafe 코드를 한정된 라이브러리 내부에 캡슐화하여, 나머지 커널 서비스는 안전한 Rust 추상화로 개발 가능하게 설계해 메모리 안전성과 단순한 공유 메모리 구조를 동시에 달성
  • RedLeaf, Tock, Rust for Linux 등 기존 Rust OS와 차별점은, 하드웨어 격리 지원 및 범용 목적, Linux 호환 ABI, 사용자 공간의 다양한 언어 실행
  • TCB(신뢰 컴퓨팅 베이스) 최소화 및 공식 검증(Verus 활용) 추진, Intel TDX 등 신뢰 실행 환경 하드웨어 지원, OSTD/OSDK 등 OS 개발 프레임워크도 별도 제공
  • 아직 초기 개발 단계로, x86/RISC-V 지원 및 206개 시스템콜 구현, Docker/컨테이너/클라우드 환경에 집중하고 있으나, X11/Xfce 등 데스크톱 확장도 시도 중

What's Asterinas?

  • Asterinas는 Rust로 개발된 Linux ABI 호환 신규 커널 프로젝트임
  • “프레임커널(framekernel)” 아키텍처란, unsafe Rust 코드(메모리 불안전 구간)를 프레임워크 라이브러리로 한정해 안전 API로 감싸고, 나머지 커널 서비스는 모두 안전한 Rust로 개발하게 설계함
  • 모놀리식 커널의 단순/고성능 구조와, 마이크로커널의 TCB(신뢰 컴퓨팅 베이스) 최소화/안전성을 동시에 추구함
  • 커널 내부에서 서비스들이 동일 주소 공간 내에서 분리되어 동작하며, 각 서비스는 core 라이브러리로부터 부여된 자원만 사용 가능함

프레임커널(framekernel) 아키텍처 설명

  • 프레임커널 개념은 "Framekernel: A Safe and Efficient Kernel Architecture via Rust-based Intra-kernel Privilege Separation" 논문에서 처음 제안됨
  • 모놀리식 커널은 모든 코드를 하나의 커널 모드 주소 공간에 포함시키는 구조이고, 마이크로커널은 최소한의 TCB에만 커널 공간을 할당하고 대부분의 기능을 유저 모드 서비스로 위임함
  • 프레임커널은 Rust의 'unsafe' 기능이 필요한 코드를 라이브러리로 캡슐화하고, 나머지 커널 서비스는 메모리 안전 Rust 추상화를 적용해 개발함
  • 각 서비스는 커널 주소 공간 내에서 실행되지만, 라이브러리에서 명시적으로 제공하는 자원만 접근하도록 제한함
  • TCB를 작게 유지하면 공식 검증(수학적 증명)이 더 용이하고, 시스템 전체의 신뢰성과 안정성을 높일 수 있음
  • 공유 메모리 기반(모놀리식 커널처럼 고성능) 이면서도, 내부 권한 분리/보안성(마이크로커널의 장점) 을 결합한 접근법임

기존 Rust OS 및 프레임커널과의 비교

  • RedLeaf: Rust 기반 마이크로커널, 하드웨어 격리를 사용하지 않음
  • Asterinas: 범용 OS, 하드웨어 격리 활용, Linux ABI 호환, 다양한 언어의 사용자 공간 실행 지원
  • Tock: 임베디드 SoC 타깃, 핵심(unsafe 허용)과 캡슐(안전 코드) 분리 구조, 하드웨어 격리 미지원
  • Rust for Linux 프로젝트 역시 커널 인터페이스를 안전 추상화로 감싸 kernel driver를 Rust로 안전하게 작성할 수 있게 하려는 목적이 있음

공식 검증 및 보안성

  • TCB를 줄이는 주된 목적은, 정형 검증(formal verification) 이 현실적으로 가능하도록 하기 위함임
  • Asterinas는 seL4처럼 작고 검증 가능한 TCB와 Linux ABI 호환, 공유 메모리 구조를 동시에 목표로 삼는 유일한 사례임
  • 보안 감사 전문 기업 CertiK와 협업하여 Verus 기반 정형 검증 작업을 수행 중임
    • CertiK의 보안 평가 보고서에서 프로젝트의 감사지점 및 발견 이슈를 공개함

라이브러리 및 개발 도구

  • 커널 자체 외에 OSTD(Rust OS 프레임워크)와 OSDK(Cargo 기반 개발 도구)를 제공함
  • OSTD의 주요 목표:
    • OS 개발 진입 장벽 완화 및 혁신 기반 마련
    • Rust 운영체제의 메모리 안전성 강화와 저레벨 API 추상화
    • Rust OS 프로젝트 간 코드 재사용 촉진
    • 유저 모드에서 신규 코드 테스트 가능(개발 생산성 증가)
  • OSD 및 OSTD 기반 커널은 Linux 호환적일 필요가 없으며, x86 하드웨어 제어, 가상 메모리, 다중 처리(SMP), 타이머 등 고레벨 메모리 안전 API를 제공
  • Intel이 후원사로 참여, 특히 Trust Domain Extensions(TDX) 와 가상머신 격리 관련 기술이 매칭

개발 현황 및 주요 스폰서

  • 2024년 초 오픈소스(MPL 라이선스)로 첫 공개, 현재 45명 기여, 주요 기여자는 중국 SUSTech, 북경대, Fudan대 박사과정과 Ant Group
  • x86, RISC-V 지원, Linux 시스템콜 206개 구현(전체 368개 중)
  • 아직 앱 실행 불가, 초기 배포판 개발·컨테이너(Docker) 지원 목표, Nix 기반 배포 등 시도
  • Linux 커널 모듈 로드를 지원하지 않으며 영구적으로 도입 계획이 없음

앞으로의 계획

  • 더 다양한 CPU 아키텍처, 하드웨어 지원 확대 및 클라우드 환경 내 실사용성을 단기 우선 과제로 삼음
  • Linux virtio 기기 지원 완료, 중국 클라우드 시장(알리바바 클라우드, Aliyun) 을 주요 타깃으로 함
  • 안전하고 축소된 TCB, Intel 신뢰 컴퓨팅 기능 지원을 갖춘 컨테이너용 host OS 개발이 중심 목표임
  • Rust for Linux와 목적은 비슷해도, Rust for Linux는 기존 커널 내 Driver의 Rust화에 제한되는 반면, Asterinas는 전체 커널 신규 설계와 TCB 최소화를 추구
  • 현재는 X11, Xfce 지원 등 다양한 방향 실험도 진행 중이며, OSTD 자체도 일반 OS 개발자에게서 주목 받을 잠재력이 있음

Rust for Linux와의 차이점

  • Rust for Linux: 기존 Linux 커널에 Rust로 안전한 드라이버만 도입, 커널 전체는 C 기반
  • Asterinas: 새로운 커널을 처음부터 Rust로 구현, unsafe를 엄격히 한정, 공식 검증 추진, 클라우드/컨테이너 환경에 집중

종합 및 전망

  • Asterinas는 메모리 안전성, 공식 검증, 클라우드 환경 실용성 등에서 혁신적 접근을 시도 중
  • 아직 실사용 예시나 넓은 커뮤니티 검증은 없음, OS 연구·클라우드·보안 분야에서 관심 받고 있음
  • OSTD 프레임워크 등은 향후 Rust OS 개발 생태계에서 활용 가능성을 가짐

Asterinas 관련 LWN 댓글 주요 논점 요약

  • Singularity OS 및 언어 기반 보안 경계 논쟁
    • Asterinas의 framekernel은 Microsoft의 Singularity OS와 유사하나, Rust의 borrow checker를 활용해 메모리 안전성을 높임
    • 언어 자체(예: Rust, Java, WASM/JS)의 보안 경계로 시스템을 보호하는 접근에 대해, "완전 신뢰는 불가능하며 실제로는 하드웨어/OS 레벨 샌드박스와 병행해서 사용함"이라는 비판과, "결함 방지 및 공식 검증에는 장점이 있다"는 의견이 대립함
    • WASM, JS, Java 등도 보안성 논란이 있지만, 실서비스에서는 언어 샌드박스만으로는 신뢰받지 못하며, 실제로는 하드웨어나 OS 샌드박스를 반드시 병행하는 사례가 일반적임
  • 운영체제 개발 트렌드 및 지정학적 배경
    • 최근 몇 년간 다양한 OS 신생 프로젝트가 등장, OS 혁신 분위기 확산 중임
    • 중국이 미국의 기술제재 및 공급망 리스크에 대응해 Linux 대체 OS 개발에 박차를 가하고 있음
    • US 제재와 GPL 등 오픈소스의 글로벌 거버넌스 논쟁, 그리고 중국·유럽 등 각국이 독립적 기술 생태계를 추구해야 한다는 정치적 논의가 격렬하게 이어짐
    • Linux에서 포크 유지와 완전 신규 커널 개발의 난이도, 커뮤니티 지식/노하우 의존성, 언어 장벽 등도 논쟁 주제임
  • Linux 호환성/시스템 콜 수 논쟁
    • "Linux 시스템 콜 수로 호환성 측정은 부적절" 의견 다수
    • 단일 시스템 콜(ioctl 등)이 수많은 세부 API를 내포하므로, 실질적 호환성을 위해서는 커널 테스트 스위트 등 실제 앱 구동이 중요
    • 초기에 POSIX 호환성 확보를 위해 syscall을 하나씩 구현했던 Linux 발전사를 예로 들며, 99%의 주요 syscall만 지원해도 꽤 많은 소프트웨어가 구동될 수 있다는 현실적 의견도 나옴
  • 라이선스 및 Rust 생태계
    • Asterinas가 MPL을 택한 것에 대한 논의: Rust의 crate 생태계와 모듈형 라이선스에 MPL이 잘 어울린다는 긍정적 의견
    • GPL이 항상 최적은 아니며, 기업 후원을 받는다면 기업 친화적 라이선스(MPL 등)를 쓸 수도 있다는 시각
  • 프로젝트 의존성/보안
    • Rust 기반 OS에서 많은 외부 crate 사용이 안전한지에 대한 의문과, cargo deny/vet 등을 통한 공급망 보안·감사 자동화 필요성 제기
    • 실제 lockfile만으로는 의존성 표면적을 파악하기 어렵고, Rust 생태계 특유의 트랜스티브 의존성, OS별 의존성 등 복잡성도 언급됨
  • 기술적 영감/유사 아키텍처
    • framekernel 개념이 90년대 University of Washington의 SPIN OS 아키텍처와 유사함을 지적
    • SPIN 역시 강한 모듈성, 컴파일러에 의한 인터페이스/접근 제어를 강조
  • 커미터 구성 논란
    • 45명의 기여자 중 다수 커밋이 소수의 박사과정 학생 중심임을 언급
    • PhD 학생 주도의 기여가 실질적 커미터로서 가치가 낮다는 오해를 지적하며, 연구 중심의 혁신 프로젝트로서도 의미가 있다는 의견
  • 정치/역사 논쟁 및 오프토픽 지적
    • OS 논의가 미국, 유럽, 중국의 지정학/정치/역사 논쟁으로 확장되며, 편집자에 의해 "오프토픽" 경고가 여러 차례 제기됨
    • 오픈소스·FOSS 생태계도 지정학적 환경 변화에 영향을 받을 수 있음을 일부 이용자들이 강조함
  • 기타
    • WASM 보안성에 관한 학술적 논문 공유
    • 커널 개발 현황에 대한 긍정적/비판적 시선 혼재
▲
eususu 2일전  [-]

이런 시도 참 좋아보입니다.
머지않아 죽지 않는 커널이 나올까 싶기도하네요.

답변달기
▲
GN⁺ 3일전  [-]
Hacker News 의견

  • 흥미로운 접근법이라는 생각, 성공을 바라는 입장임. 하지만 여전히 의구심이 남음. 90년대 말이나 2000년대 초에 Linus가 TV 인터뷰에서 경쟁자에 대해 언급한 내용이 아직도 기억에 남음. Linus는 "드라이버를 쓰는 걸 즐기는 사람은 없음, 젊고 굶주린 누군가가 뛰어난 드라이버 엔지니어로 나오기 전까지는 안전함"이라는 식으로 말한 적이 있음. 이미 그 당시에도 드라이버 인터페이스를 불안정하게 유지하는 것이 방어책임을 인지하고 있었음. 25년이 지난 지금, 가상화 하드웨어에서 동작하는 커널은 아주 흔하지만, 여전히 진짜 하드웨어와 추상화에 성공한 실질적이고 사용 가능한 운영체제는 손에 꼽을 정도임

    • "드라이버 인터페이스를 불안정하게 유지하는 것이 방어책"이라는 부분에서, 앞으로는 젊고 굶주린 시스템 연구자나 AI가 등장해서, AI 에이전트가 C로 된 Linux 드라이버를 안전한 Rust로 된 Asterinas 드라이버로 번역해주는 방향이 가능성이라는 생각. 또 다른 현실적인 접근법은 리눅스 커널 자체를 어떤 격리 환경 안에 넣어 재활용하는 것임. 예를 들어 HongMeng 커널은 User-Mode Linux를 활용해 드라이버를 재사용함. Asterinas도 이와 유사한 전략 적용이 가능함. 참고: https://www.usenix.org/conference/osdi24/presentation/chen-haibo

    • Linus가 진짜로 "방어벽"을 원하거나 의도했을지에 의문인 입장임. 기술 스타트업 창업자가 아니고, 원래 그냥 커널 해커였으며 이미 평생 먹고 살 기반은 다 마련됨. 커널 내의 드라이버 인터페이스 불안정성이 의도적 경쟁 방지 전략이라는 해석은 너무 과한 투영임

    • 과거에도 SPIN OS(Modula 3), JX OS(Java), House OS(Haskell), Verve 같은 선례가 있음. 모두 타입 세이프와 메모리 세이프 언어를 사용해 커널 기능을 구현했었음. 일반적으로 위험을 체크된 함수 호출 뒤에 숨겨둔 구조, 일부는 VM 활용. 성능이나 채택 문제 제외하면 주된 취약점은 추상화의 빈틈, unsafe 코드 우회, 컴파일러/JIT로 인한 세이프티 모델 붕괴, 일반적인 하드웨어 결함(예: 우주선에서의 코스믹 레이). 그래도 unsafe 언어 커널/앱보다는 훨씬 더 안전함. 여기서 더 나아가려면, unsafe 코드의 정적 분석, 모든 unsafe 함수가 타입-메모리 세이프 인터페이스를 준수함을 보장, 통합 시 추상화 세이프티 preserving 컴파일러, 구성 요소별 인증된 컴파일러도 활용 가능. 생산성 툴은 대부분 존재하고, 단지 하나가 '완전히 안전하게 추상화된 컴파일'인데, 현재 연구 중이며 수작업 검사도 가능함

    • 실질적으로 사용 가능한 운영체제 수가 손에 꼽힌다는 점에는 이유가 있음. 하드웨어 세계에는 인터페이스 '표준'이 넘쳐나지만, 실제 하드웨어는 표준대로 잘 동작하는 경우가 거의 없음. 드라이버가 각종 특이점과 수정 불가한 결함(에라타)을 대응하도록 코드를 작성해줄 시간이 들지 않으면, 실제 물리 하드웨어에서 성능과 지원을 가지는 것은 정말 어렵다는 현실임

    • 한편으로 실제로 내가 다루는 Linux의 98%는 가상화 환경에서 동작함. 데스크톱/랩탑에서는 Virtualbox를 전체화면으로 돌리고, 윈도우용 드라이버는 정말로 필요할 때만 사용하며, Mac에서는 Docker.app로 관리되는 헤드리스 VM. 회사의 모든 운영 워크로드는 AWS VM. 집에서 사용하는 유일한 리눅스 하드웨어도 홈서버고 곧 이베이에서 산 Mac mini VM으로 대체할 계획. 만약 리눅스와 호환되면서 보안성이 더 높고 성능도 비슷한 커널이 나온다면, 드라이버가 부족하더라도 요즘은 대안 선택이 쉽다는 생각

  • 최근 마이크로커널이 IPC 성능 이슈를 많이 개선했다고 들었음. 실제 어느 정도 개선됐는지는 기억이 가물하지만, Mach로 인한 업계 트라우마가 컸던 것 같음. 프로젝트 사이트를 보면, 오히려 Framework(특권 모드)만 Rust의 unsafe를 쓸 수 있고, Services(비특권)는 안전한 Rust만 사용한다는 구조임. 어딘가 어색한 느낌인데, 비특권 코드가 unsafe하면 아무리 비특권이라도 위험한 것 아닌지? 반면 정말 검증이 필요한 unsafe 코드는 무제한으로 쓸 수 있는 쪽임? 그리고 라이선스를 보면, Asterinas는 Mozilla Public License(MPL) 2.0을 주로 사용하며, 일부 구성 요소는 더 관대한 라이선스라는 설명. GPL도 아니고, BSD도 아닌 중간 정도 느낌임

    • "비특권이 unsafe여도 위험하고, 정말 검증 필요한 코드는 특권쪽에만 몰아둔다는 게 이상하다"는 질문에, 이 구조는 framekernel 컨텍스트에서 해석해야 함. Rust 기반 framekernel 전체는 커널 공간에서 동작하지만, 논리적으로 특권 OS 프레임워크와 비특권 OS 서비스 두 부분으로 나뉨. 특권은 safe + unsafe Rust 커널 코드 모두 포함, 비특권은 오직 safe Rust 커널 코드만 포함. 이 정책은 모두 커널 코드에 해당되는 내용임. framekernels에서는 유저 프로그램 언어에 제약이 없음

    • 최근 마이크로커널들은 대부분 IPC 성능을 극적으로 개선한 것으로 알고 있음. 대표적으로 SeL4는 IPC를 매우 공격적으로 최적화해, 리눅스의 일반적인 syscall보다 IPC가 훨씬 빠름. 웬만한 대부분 프로그램은 Sel4에서 오히려 더 빠르게 동작할 가능성이 있음. 실제 성능 비교 데이터가 궁금함

    • 최신 마이크로커널들이 IPC 이슈를 개선한 것이 맞음. 사실 더 근본적인 문제는 현대 하드웨어에서 심지어 모놀리식 커널의 syscall조차 매우 느리다는 점임. 그래서 io_uring이나 virtio 같은 인터페이스가 좋은 성능을 내는 이유가 시스템과 앱(또는 하이퍼바이저와 게스트) 간에 요청과 응답을 큐로 처리해서 어드레스 스페이스 전환을 피하기 때문임. 앞으로의 운영체제는 어떤 구조든 '큐잉' 기반 syscall 메커니즘이 필수임. 그리고 이 방식을 택하면 OS를 모놀리식/마이크로커널/기타 구조로 나누든 상관없이 성능상의 큰 차이 없음

    • Framekernel에서 privileged/unprivileged 분리가 커널/유저스페이스 의미가 아님. OS 전체가 커널 privilege 레벨에서 동작. 단, 논리상 코어 라이브러리 코드(unsafe 사용 허용, privileged)와 나머지 커널 구성 코드(라이브러리 이용, unsafe 직접 사용 불가, unprivileged)로 나눔. 아마도 linter 등 정적 체크로 강제함. 용어의 중복사용 때문에 헷갈리기 쉬운 구조임

    • 비특권 task도 커널 코어와 같은 메모리 공간에서 동작하므로, 런타임에서 안전하지 않은 동작을 막을 방법이 없음. 실제로 런타임에서 특권을 분리하려면 마이크로커널 구조가 필요함. 여기서는 특권을 런타임이 아닌 정적으로, 즉 unsafe 코드를 금지하도록 해서 권한을 구현함

  • 커널을 작은 unsafe 코어와 대형 safe 모듈로 분리하는 개념이 새로운 시도인지 궁금함. 마이크로커널의 하드웨어 오버헤드는 없고, 모놀리식의 안전성 이슈도 피하면서, 시스템 언어의 safe/unsafe 구분 성질을 잘 살린 프로젝트라는 점에서 흥미와 기대감이 큼

  • Drew DeVault의 Rust in Linux 리뷰 글이 떠오름. HN 토론도 연결 가능함 https://news.ycombinator.com/item?id=41404733

  • 정말 대단한 시도라고 생각, 작성자가 이 스레드에 있다는 점도 감동. 어느 수준까지 usable한지 궁금함, 일부 제한적 환경에서라도 서버 이미지를 빌드해서 실험하고 싶음

    • Asterinas는 아직 상대적으로 새로운 커널이라 범용 사용에는 다듬어야 할 점이 많음. 하지만 실제로 효율적이고 신뢰할 만한 실서비스 운영을 목표로 한다면 그 격차는 그리 크지 않고, 1년 이내에 목표 도달 가능성 있음. 현재 Linux 네임스페이스, cgroups 같은 핵심 기능 구현과 최초의 Asterinas 기반 배포판 작업이 진행 중. 초기 목표는 Confidential VMs의 게스트 OS로 Asterinas를 활용하는 것이며, 메모리 안전성과 작은 TCB 덕분에 보안 측면에서 Linux보다 명확한 강점이 있음

  • 마이크로커널 IPC가 느려서 인기가 적다는 설명을 보며, 기술적으로 뛰어난 사람들도 실제 채택 이유와 그 과정에서 오해를 하는 것 같아 안심

    • 그렇다면 정확히 어떤 점에서 잘못 해석되고 있는지 알려줘야 모두에게 도움이 될 것임

  • 라이선스가 MPL인데, 개인적으로는 더 나은 라이선스(GPLv3 등)도 있다고 생각함

    • 문서에서 MPL을 선택한 이유를 직접 설명하고 있음. 내가 좋아하는 선택은 아니지만 이유는 납득 가능함

  • 정말 괜찮은 아이디어라는 생각. 이미 많은 소프트웨어가 구축돼 있고, 대안적 기반이 있으면 기술 외적인 이유들로도 큰 이점이나 선택지가 생길 수 있음. kFreeBSD, GNU/Hurd가 떠오름

  • 이런 커널들은 뭐라고 불러야 할 지 고민. *nux?

답변달기