▲

Munal OS - WASM 샌드박싱이 적용된 그래픽 기반 실험용 운영체제

 (github.com/Askannz)
12P by GN⁺ 2일전 | ★ favorite | 댓글 1개
  • Rust로 완전히 구현되어 있으며, unikernel 설계와 WASM 기반 샌드박싱 보안 모델을 사용하는 그래픽 기반 실험용 운영체제
  • EFI 바이너리에 커널, WASM 엔진, 모든 앱이 내장되어 최소화된 구조와 독특한 시스템 호출 인터페이스를 제공
  • VirtIO 기반 드라이버를 통해 QEMU에서 동작하며, 입력 및 네트워크, GPU 관리가 인터럽트 없이 폴링 방식으로 구현
  • 전역 이벤트 루프와 협동 스케줄링을 통해 단순화된 동작 구조와 애플리케이션별 자원 모니터링 기능을 지원
  • 자체 UI 툴킷 Uitk와 내장 앱(웹브라우저, 텍스트 에디터, Python 터미널) 제공, 다양한 언어로 WASM 앱 개발 가능

Munal OS란

  • Munal OS는 Rust로 완전히 개발된 실험용 운영체제로, unikernel 기반 아키텍처와 WASM 샌드박싱을 조합해 새로운 OS 설계를 탐구하기 위해 만들어진 프로젝트
  • 복잡성을 줄이고 필수 요소만 적용해, 현대적 도구로 간소화된 시스템 구조 실현을 목표로 함

주요 특징

  • 풀 그래픽 환경 및 HD 해상도 지원, 마우스 및 키보드 인터페이스 탑재
  • 샌드박스 방식 앱 실행, 사용자 애플리케이션의 커널 메모리 접근 차단
  • 네트워크 드라이버 및 자체 TCP 스택 내장
  • 커스터마이즈 가능한 UI 툴킷(Uitk) 포함, 다양한 위젯과 유연한 레이아웃, 텍스트 렌더링 지원
  • 기본 제공 앱: 웹 브라우저(DNS, HTTPS, 기초 HTML 지원), 텍스트 에디터, Python 터미널

아키텍처

  • EFI 바이너리 기반 구조

    • 부트로더 없이 EFI 바이너리 형태로 구동, 커널/WASM 엔진/앱이 한 파일에 내장됨
    • UEFI 부트 서비스는 최단시간 내 종료, 시스템 시계 외에는 추가 활용 없음

  • 주소 공간 관리

    • 가상 주소 공간 미사용, UEFI가 남긴 identity-mapped 주소 그대로 사용
    • 페이지 테이블 변경 없음. 커널 메모리 직접 보호는 WASM 샌드박싱으로 보완

  • 드라이버와 하드웨어 지원

    • PS/2나 VGA 대신, VirtIO 1.1 사양을 활용하는 PCI 드라이버 직접 구현
      • 키보드, 마우스, 네트워크, GPU용 드라이버 제공
    • 인터럽트 미사용, 모든 드라이버는 폴링 방식으로 설계
    • QEMU 이외의 실물 하드웨어 실행은 미지원, 향후 추가 개발 필요

  • 이벤트 루프와 스케줄링

    • 멀티코어/인터럽트 미지원, 전체 동작은 단일 전역 이벤트 루프에서 선형적 실행
      • 각 루프마다 네트워크/입력 드라이버 폴링, 데스크탑 UI 및 앱 실행, GPU 프레임버퍼 갱신
    • 성능 분석 용이, 각 루프 사이클별 타임 측정 가능
    • 앱은 직접적으로 CPU 점유 해제 필요, 장기 작업은 명시적으로 양보 필요
    • 협동 스케줄링 기반이나, Wasmi 엔진의 fuel limit 기능을 통한 오작동 앱 강제 종료 지원 가능(미구현)

응용 프로그램 실행 구조

  • [Wasmi WASM 엔진] 내장, 앱 실행시 완전 샌드박싱과 커널 분리 제공
  • 커널 차원에서 시스템 콜 API 제공, 앱에서 마우스/키 이벤트 조회, TCP 소켓 사용, 프레임버퍼 출력 등 가능
  • 앱의 렌더링 결과는 OS가 데스크탑에 합성하여 출력
  • Rust 이외의 언어로도 앱 제작 가능, WASM 빌드만 지원하면 사용 제한 없음
  • WASI 호환성은 부분 지원. 완전 준수 아님, 주요 외부 종속성 활용을 위한 최소 구현만 포함
  • 앱별 전용 로그 스트림(stdout 유사) , 데스크탑 ‘감사’ 뷰에서 리소스 사용량과 함께 확인

UI 툴킷(uitk)

  • Munal OS와 WASM 앱 모두에서 사용하는 자체 즉시모드 UI 킷
  • 기본 위젯(버튼, 프로그레스바, 텍스트 에디트, 스크롤 캔버스) 및 삼각형 래스터라이저 제공
  • 글로벌 스타일시트 기반 통일 스타일링, 개별 요소별 오버라이드 지원
  • 효율적인 캐싱 시스템으로 불필요한 리렌더링 방지
    • 각 영역별 “타일” 구분, Rust 뮤터빌리티 규칙 기반 변경 감지 알고리듬

빌드 및 실행 환경

  • Rust Nightly 2025-06-01 및 QEMU 10.0.0 이상에서 빌드 및 실행 가능

주요 참고 자료 및 크레딧

  • Philipp Oppermann의 Rust OS 튜토리얼 및 OSDev Wiki 문서
  • Wasmi, smoltcp, Rustls, RustPython 등 주요 오픈소스 활용
  • 다양한 오픈 소스 폰트 및 아이콘, 월페이퍼 자료 사용

Munal OS의 의의 및 장점

  • 단일 EFI 바이너리 구조와 혁신적 샌드박싱 결합으로, 기존 OS 설계 패러다임 재고
  • QEMU 환경 최적화 및 독특한 폴링 기반 드라이버 구조, 실 시스템 하드웨어 의존성 최소화
  • 시스템 리소스 관리 투명성, 단순 구조에서 얻는 학습 및 실험적 가치가 큼
  • 언어나 환경 제약 없이 WASM 앱 생태계 확장 가능성이 큼
▲
GN⁺ 2일전  [-]
Hacker News 의견

  • 매 반복마다 네트워크와 입력 드라이버를 폴링하고, 데스크탑 인터페이스 그리기, 각 활성화된 WASM 애플리케이션을 한 단계 실행한 뒤 GPU 프레임버퍼를 플러시하는 구조임에 흥미로움을 느낌. 이 기능을 Wasmi로 어떻게 구현했는지 궁금해서 코드를 찾아봤음 GitHub 코드 링크. 최신 Wasmi(v0.45+)에서는 fuel이 부족할 때 yield 할 수 있도록 resume 가능한 함수 호출 기능이 확장됨을 안내하고 싶음 Wasmi 문서 링크. 이미 fuel metering을 사용하고 있어서 실행 단계에서 더 효율적인 방법이 될 수 있음. 활용 예시는 Wasmi Wast 러너 예제에서 확인 가능함

    • 다시 한 번 Wasmi를 만들어줘서 고마움을 느낌. Wasmi에 fuel이 떨어졌을 때 yield할 수 있는 기능 소식이 정말 흥미로움. 예전 문서에서는 이런 기능을 찾지 못해 아쉬웠는데, 만약 있었더라면 WASM 앱 디자인 방향이 달랐을 것임
    • OP는 아니지만, 이 기능이 왜 도움이 되는지 이해가 잘 안 됨. 함수로 코루틴을 만들고 시작한 후 만약 실행 중 메모리가 부족해 실패했다면 추가 메모리를 주고 코루틴을 다시 resume할 수 있다는 의미인지 질문. 그렇다면 기존의 동작과 무엇이 다른지 궁금함. WASM에서 try/catch가 없는지도 물음. 실패한 상태에서 malloc을 명시적으로 다시 시도해야 한다면, 그렇게까지 해서 얻는 차이가 명확하지 않아 혼란스러움
    • Wasmi가 GUI 앱을 실행할 정도로 빠르다는 점에 흥분을 느낌. 나는 휴대성과 이식성이 높은 GUI 앱을 만들기 위한 앱 런타임을 개발 중임. 퍼포먼스와 구현 간결함의 균형을 위해 wasm을 선택했고, 사실상 몇 명 혹은 한 명의 팀만으로 런타임을 뚝딱 구축하는 게 가능하길 바람. Wasmi처럼 최적화된 해석기 기반 wasm 런타임이 GUI 앱도 무리 없이 돌릴 수 있다는 사실에서 상당한 가능성을 느낌

  • VirtIO에 의존하는 구조라서 Munal OS는 아직 실제 하드웨어에서는 동작하지 않는다는 점을 언급하며, 만약 실제 하드웨어에서 운영하려면 직접 드라이버를 추가하는 대신 리눅스를 부트로더로 쓰고 미니멀 하이퍼바이저에서 운영체제를 구동하는 전략도 재미있는 접근이라 생각함. 이런 방식이면 "VirtIO가 플랫폼"이라는 컨셉을 유지할 수 있음. 앱 실행에는 WASM, 플랫폼에는 VirtIO를 택하는 구조로 정체성을 지키는 점이 멋짐. 하지만 보안 관점에선 MMU 사용이 필요함. 설계상 가상 메모리까지 도입하지 않아도 되지만, 보호 비트를 쓰기 위해 페이지 테이블과 TLB 관리 등 추가 복잡성이 생겨 단순함이 다소 약화됨

    • 마지막 해킨토시 시도에서 리눅스를 부트로더 겸 미니멀 하이퍼바이저로 삼아 비슷하게 운영해봤고 효과도 괜찮았음. 단점은 실제 GPU 이벤트 없이 리눅스가 결정한 해상도와 설정대로 고정되어 자유도 제한이 있음. 만약 이 OS가 진짜 OS가 아니라 UEFI 실행 파일로 작동할 수 있다면 UEFI 비디오 드라이버만으로도 그래픽 처리 가능성이 있으나, 실제로 OS다운 기능을 가지면서 시도할 수 있는지는 확신 없음

  • 반복 루프가 오래 CPU를 점유하면 안 되고, 장시간 작업은 반드시 명시적으로 yield해야 한다는 점보다 더 큰 단점은, 앱을 많이 열수록 각 앱의 처리 속도가 느려진다는 것이라 생각함. 직접 10개 넘게 앱을 띄운 적은 거의 없지만, 탭은 30개까지 열어본 경험 기준, 각각이 프로세스라면 성능 저하가 확연하게 발생할 것임. 하드웨어가 충분히 빠르면 문제 없겠지만, 예를 들어 동영상 렌더링 등 무거운 처리는 1초에서 30초로 느려지는 등 큰 차이를 체감할 수 있음. 그럼에도 불구하고 전체 OS를 이렇게 구현했다는 점 자체가 아주 똑똑하며 정말 대단하고 신나는 시도임

    • 앱들이 할 일을 제시간에 끝내기만 하면 절대 느려질 필요 없음. 실행해서 끝내고, 다음 프레임을 기다리는 식임. 자원이 모자라서 대기 시간이 0 이하가 되면 전체적으로 느려지지만, 복잡한 공정한 스케줄러보다는 덜 우아한 방식임. 각 프로그램은 자신이 프레임 준비가 끝나면 명시적으로 yield하는 구조라서, 할 일 없는 앱은 시간을 거의 쓰지 않음

  • 협력적 스케줄링 외에도 Spectre 공격 방어가 까다로워 보이고, 가상 메모리 없이 효율성이 나올지 의문임. 예를 들어 WASM에서 memory.grow를 처리할 때 다른 앱 메모리가 걸리면 전체를 memmove해야 되는 상황이 생길 수도 있는데, 이게 과연 가능한지 궁금함. 그럼에도 정말 인상적인 프로젝트임

    • Spectre가 공격 벡터라면, 정확히 어떤 위협 모델이 전제되어 있는지 질문. 현재 구조상 모든 앱이 커널에 직접 컴파일되고 웹브라우저도 자바스크립트를 실행하지 않는 상태라, 신뢰할 수 없는 코드 유입 경로 자체가 없어 보임
    • 자세한 설명을 부탁드림

  • wasm 컴포넌트가 실현될 때 이런 시도들이 어떻게 바뀔지 궁금함. unikernel 디자인을 높이 평가하고, Munal OS가 다양한 기능을 가진 점도 인상적임. wasm을 단일 대형 앱 용도가 아닌 다수 작은 프로세스와 서브 환경을 호스팅하는 데도 활용되길 기대함. wasi preview3에서 동기/비동기 공존 가능성이 곧 열리고, 그렇게 하면 wasm이 범용 런타임의 요소를 다 갖추게 될 것임. 여전히 호스트 오브젝트 브리징이 JS에 치중된 현실이 아쉽지만, wasm 컴포넌트의 약속(표준, 경량, 샌드박스, 언어 간 조합)을 진짜 실행 가능한, 하나의 분산 포맷이 아닌 런타임 역량으로써 현실에서 보여주길 바라는 마음임. 아래 토크도 참고함 What is a Component (and Why)

    • 이 주제를 말할 때 혹시 이 영상 유튜브 링크를 언급하려고 했던 건지 질문함
    • 나는 SDL3를 지원하고, V8을 내장해 스크립팅이 가능한 Rust 앱을 만들기 시작함 블로그 소개. 하지만 진지하게 고민하는 건, 이를 fork해서 wasmtime이나 wasmi를 임베딩해 어떤 언어로든 스크립팅 가능하도록 만드는 것임. 컴파일러도 같이 내장해 파일만 주면 바로 스크립팅되는 구조를 만들 수 있을 것임. wasmtime과 wasmi가 다른 스크립팅 엔진들보다 빠르기 때문임 비교 데이터. 다만 불편한 점은 코드 환경을 전부 셋팅해야 해서 스크립트로써 진입장점이 약하다는 것임. 그래도 아이디어 자체가 너무 멋져서 한번쯤 해보고 싶음

  • “The Birth and Death of Javascript” Pycon 2014 토크에서 asm.js(현 wasm의 전신)로 OS 샌드박스를 구현하는 미래를 소개한 부분을 봤는데, 이 아이디어가 이 프로젝트 설계의 핵심과 비슷해 보여서 혹시 영향을 받았는지 궁금함 토크 링크

    • 오히려 Microsoft의 연구용 OS인 Midori에 더 영향을 받았을 가능성이 높다고 생각함 Midori 소개

  • 이 OS엔 자체 웹 브라우저까지 내장되어 있어서 놀라움을 느낌 웹 브라우저 소스. 데모 영상에서 Hacker News를 랜더링하는 모습도 확인 가능함

    • 웹 브라우저에 JS, CSS 등 기능이 쏟아지기 이전에는 이렇게 작은 브라우저가 최소한의 의존성으로 웹을 볼 수 있었지만, 지금은 오히려 대부분의 웹을 유의미하게 볼 수 없다는 점에서 아쉬움을 느낌. 컨텐츠 중심 웹과 앱 중심 웹을 좀 더 명확히 분리할 필요가 있다고 생각함. 컨텐츠 웹은 아주 단순한 HTTP 클라이언트와 HTML 파서만 필요하고, 웹 앱들은 이 OS와 비슷하게 wasm 기반 + 소수 하드웨어 API만 있으면 충분함. 단, 반드시 UDP 지원 필요함

  • 놀랍다는 느낌과 함께, 이런 구조가 OS의 미래가 될 수 있을지 궁금증을 느낌. readme 자체도 상당히 흥미로움. wasmi 대신 wasmtime을 선택하지 않은 이유가 궁금함. 나도 VM에서 이 OS를 직접 써보고 싶고, 내 GUI 라이브러리를 Munal에 포팅하고 싶은 욕심도 있음

    • wasmtime을 no_std 모드로 빌드하는 게 너무 까다로워서, 결국 wasmi를 선택했다는 경험을 공유함
    • 최신 OS 구조의 미래 얘기에 SPECTRE와 MELTDOWN이 끼어드는 농담을 추가함
    • 앱 격리를 가상화로 한다는 점에서 Qubes OS에서도 이미 비슷한 미래를 체험 중임을 언급. 거기서는 앱 격리가 아주 확실하게 이루어짐

  • Xerox PARC 시절부터 꾸준히 "유저스페이스를 바이트코드화하려는 시도"가 반복되어 왔고, 실제로 시장에서 성공한 사례는 IBM i, ChromeOS, Android 정도뿐이라 봄. 다만 이 프로젝트는 멋지며 잘 되길 바람

    • WebAssembly 관련 스레드마다 본인이 오래된 바이트코드 VM 얘기를 반복하는 모습이 이제 패턴처럼 느껴짐. 매번 똑같은 논조로 반복 평가하는데, 개발자 커뮤니티에서는 다양한 시행착오와 새로운 접근이 필연적으로 나오기 마련임을 강조하고 싶음. 기본적인 패턴 인식 대신 더 세부적인 의견을 듣고 싶다는 바람임
    • 이런 개념이 워낙 장점이 명확해서, 표준으로 제대로 자리잡기 전까지 계속 새로운 시도가 반복될 수밖에 없음. wasm은 실제로 그걸 목표로 하는 점에서 JVM 등과 확연히 다름
    • ChromeOS는 단지 브라우저이기 때문에 우연히 V8을 쓸 뿐이고, Android는 무엇을 사용해도 성공했을 거라고 생각함. 두 OS가 잘 된 요인은 기술이 아니라 가격 때문임

  • 클라이언트 OS 설계 자체가 놀라움. 이런 구조는 서버에서도 즉각적으로 실용성 있을 것으로 봄. 커널을 아주 작게 만들고 동작하는 단일 앱만 남겨두면 불필요한 보안 경계를 줄일 수 있다고 생각함. 예를 들어 key/value store가 이런 구조에 적합할 것임. 궁금한 점은 이 IO 모델로 네트워크 성능이 잘 나오는지, 그리고 WASM 호스팅 시 불필요한 메모리 복사를 줄이기 위한 특별한 기법이 적용될 수 있는지임

답변달기