Maestro: 리눅스 호환을 목표로 한 Rust 기반 커널

 (blog.lenot.re)
3P by GN⁺ | ★ favorite | 댓글 1개
  • Maestro는 일상 사용이 가능할 만큼 Linux와 호환되면서도 가벼운 Unix 계열 운영체제를 Rust로 새로 만들려는 프로젝트임
  • 2018년 학교 프로젝트로 시작해 초기에는 C 언어로 구현됐지만, 코드베이스 관리 문제와 커널 개발의 안전성 요구 때문에 Rust로 전환함
  • 현재는 x86 32비트용 모놀리식 커널이며, Linux 시스템 콜 437개 중 135개가 어느 정도 구현돼 약 31% 수준임
  • 부트 시스템·데몬 관리자 Solfège, 시스템 유틸리티, 패키지 관리자 blimp를 함께 만들고 있으며 musl, bash, 일부 GNU coreutils도 동작함
  • 아직 매우 초기 단계라 불안정하며, QEMU·VMWare·VirtualBox 테스트가 중심이어서 중요 데이터가 있는 머신에는 설치하지 않는 편이 안전함

Maestro의 목표와 출발점

  • Maestro는 Rust로 처음부터 작성한 Unix 계열 운영체제임
  • 목표는 가볍고, 일상 사용이 가능할 정도로 Linux와 충분히 호환되는 시스템을 만드는 것임
  • 직접 시스템을 A부터 Z까지 이해하고 원하는 방식으로 커스터마이즈할 수 있는 환경을 만들기 위해 시작됨

C에서 Rust로 전환한 이유

  • 첫 커밋은 2018년 12월 22일 03:18에 만들어졌고, 프로젝트는 학교 과제로 출발함
  • 초기 구현은 약 1년 반 동안 C 언어로 진행됐지만, 코드베이스를 깨끗하게 유지하기 어려워짐
  • Rust로 다시 시작하면서 얻은 장점
    • 이전 실수에서 배운 내용을 바탕으로 프로젝트를 처음부터 재설계할 수 있음
    • 단순히 C로 Linux 비슷한 커널을 다시 쓰는 것보다 더 새로운 시도를 할 수 있음
    • Rust 타입 시스템 덕분에 메모리 안전성의 일부 책임을 프로그래머가 아니라 컴파일러가 맡을 수 있음

커널 개발에서 Rust가 유리했던 지점

  • 커널 개발 디버깅은 일반 애플리케이션보다 훨씬 까다로움
    • 문서를 찾기 어렵고, BIOS 구현 자체에 결함이 있을 수 있음
    • 부팅 시 커널은 메모리 전체에 접근할 수 있어 자기 코드 같은 잘못된 위치에도 쓸 수 있음
    • 메모리 누수 추적에 valgrind 같은 도구를 사용할 수 없음
    • gdb는 QEMU·VMWare와 함께 사용할 수 있지만, 에뮬레이터나 가상머신에 따라 커널 동작이 달라질 수 있음
    • VirtualBox처럼 gdb를 지원하지 않는 환경도 있고, QEMU·VMWare의 gdb 지원 기능도 일부 빠져 있으며 gdb가 충돌할 때도 있음
  • 이런 문제를 줄이려면 메모리 안전 언어가 커널 개발에서도 유리함
  • Rust는 커널에 여러 안전장치를 넣는 데 도움이 됐고, 프로젝트에서 가장 좋은 결정으로 평가됨

현재 구현 상태

  • Maestro는 현재 모놀리식 커널이며 x86 32비트 아키텍처만 지원함
  • 작성 시점 기준 구현 상태
    • Linux 시스템 콜 437개 중 135개가 어느 정도 구현됨
    • 시스템 콜 구현률: {p:31}
    • 전체 저장소 합산 기준 615개 파일, 48,800줄의 코드가 있음
    • 줄 수는 cloc 명령으로 계산됨
  • 커널 외 OS 구성요소
    • Solfège: systemd와 어느 정도 비슷하지만 더 가벼운 부트 시스템·데몬 관리자
    • maestro-utils: 시스템 유틸리티 명령 모음
    • blimp: 패키지 관리자
    • 그 외 구성요소는 GitHub에 공개돼 있음
  • 동작이 확인된 서드파티 소프트웨어
    • musl C 표준 라이브러리

    • bash

      • ls, cat, mkdir, rm, rmdir, uname, whoami 등 일부 GNU coreutils 명령
      • 원본 neofetch가 Maestro를 알지 못해 패치된 neofetch 버전이 필요함

직접 테스트하는 방법과 제약

  • OS는 아직 매우 초기 단계이며 매우 불안정함
  • 중요 데이터가 있는 머신에 설치하는 것은 권장되지 않음
  • 지금까지 주로 QEMU, VMWare, VirtualBox에서 테스트됨
  • 설치 방법은 두 가지임
  • ISO에는 OS 설치 프로그램이 포함돼 있으며 QEMU, VMWare, VirtualBox 등에서 실행할 수 있음
  • ISO 실행에는 충분한 RAM이 필요하고 1GB면 충분함
    • 설치할 패키지가 디스크가 아니라 initramfs의 RAM에 저장되기 때문임
    • 현재 OS가 USB 스틱이나 CD-ROM을 직접 읽을 수 없어 부트로더에 의존함

글에서 다룰 주제

  • 목표는 OS 제작 튜토리얼을 쓰는 것이 아님
  • OS 제작 기초 자료로는 osdev.org와 Philipp Oppermann’s blog가 추천됨
  • 앞으로는 더 고급 주제, 문제 해결 과정, 컴퓨터·운영체제·인터넷이 내부에서 동작하는 방식을 다룰 예정임

앞으로의 개발 방향

  • 우선순위는 코드베이스 정리와 성능 최적화임
  • 학교 프로젝트로 시작해 일정에 맞추기 위해 지름길을 택한 부분이 있고, 누적된 기술 부채를 갚아야 함
  • 일부 메모리 누수도 수정해야 하며, 성능 최적화는 글 주제가 될 수 있음
  • 다음 큰 목표는 패키지 관리자가 OS 위에서 완전히 동작하게 만드는 것임
    • 네트워크 지원이 필요하며 현재 개발 중임
    • 공유 라이브러리 지원이 필요함
    • 공유 라이브러리는 파일을 메모리에 직접 매핑해야 하지만, 현재 커널의 mmap 시스템 콜 구현은 이를 지원하지 않음
  • 이후에는 gcc/g++, clang, rustc, make, Git, Vim 같은 프로그램을 더 쉽게 설치하고 테스트할 수 있음
  • 최종적으로는 Maestro 위에서 커널을 개발하는 흐름을 목표로 함

커널 완성도를 높이는 개발 절차

  • 개발은 프로그램을 커널에서 실행해 보고, 동작하지 않으면 원인이 되는 시스템 콜을 찾아 구현하거나 수정하는 방식으로 진행됨
    • 프로그램을 커널에서 실행함
    • 동작하지 않으면 시스템 콜 출력을 보며 처음 문제를 일으키는 시스템 콜을 찾음
    • 해당 시스템 콜이 미구현이거나 버그가 있으면 구현 또는 수정함
    • 다시 프로그램을 실행함
  • 더 많은 프로그램이 커널에서 올바르게 동작할수록 커널은 더 안정적이고 완성도 높아짐

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • 응원해줘서 정말 고맙고, 이 프로젝트에 많은 노력을 들였기 때문에 큰 의미가 있음
    지금 웹사이트가 꽤 느리거나 내려간 것 같은데, 예상보다 트래픽이 많고 DoS 공격도 의심됨
    지금은 직장에 있어서 바로 집중하긴 어렵지만, 집에 가면 더 잘 동작하게 고쳐보겠음

    • HN 자체 Slashdot 효과로 인한 DoS 같음
    • 멋진 프로젝트이고, 여기서 bash 실행까지 된다는 건 큰 이정표처럼 보임
      2010년에 Rust가 없던 시절, 대학 졸업 직후 C로 유닉스 계열 취미 OS를 조금 만져봤는데 정말 재미있었음
      여기까지 올 시간을 낼 수 있었다는 게 부러움
    • 모바일에서도 웹사이트를 테스트해봤으면 함
      내비게이션 바가 화면의 33%쯤 차지하고 제거할 수 없음
      왜 사람들이 이런 걸 고정해서 귀한 읽기 공간을 빼앗는지 모르겠음. 원하면 300ms 정도면 맨 위로 스크롤할 수 있음

  • 작고 멋진 프로젝트임. Linux의 시스템 호출 중 3분의 1도 구현하지 않았는데 이렇게까지 부팅된다는 게 놀라움
    다만 빠진 것들이 더 복잡한 것들일 가능성이 큼. 예를 들어 TTY 계층은 지금 꽤 기본적인 수준으로 보이고, 제대로 만들려면 일이 많을 것 같음
    그래서 앞으로 3년 안에 Maestro가 Linux 애플리케이션을 돌릴 거라고 기대하긴 어려움. Linux가 가진 수천 개 드라이버까지 고려하지 않아도 그렇다

    • 훌륭한 프로젝트지만, 그 비율 자체는 전혀 놀랍지 않음
      성숙한 플랫폼은 여러 시나리오를 지원하려고 로직이 쌓이고, 그래서 대부분은 시스템 전체의 대부분을 필요로 하지 않게 됨
      “누구도 Excel의 10% 이상을 쓰지 않지만, 각자가 쓰는 10%는 다르다”는 말과 비슷함
      Excel 함수의 30%만 구현해도 세상에 있는 스프레드시트의 99%를 여는 엔진을 만들 수 있을 것임. 다만 완전한 문서 호환성을 원하면 아직 갈 길이 멂
    • 내 취미 OS는 특정 언어 VM 하나를 위한 FreeBSD 호환 커널에 가까움. 424개 중 61개 시스템 호출을 지원하고, 한동안 빠뜨린 호출을 만난 적이 없음
      어떤 시스템 호출은 특정 코드 경로에서만 호출되거나, 더 새 커널을 대상으로 할 때만 필요한 새 호출일 수 있음
      시스템 호출은 많고, 그중 꽤 난해한 것도 있음. 완전히 열린 대체 구현이라면 결국 대부분을 지원해야겠지만, 3분의 1이면 좋은 출발임
      [1] VM을 베어메탈에서 돌리거나 VM으로 부팅하고 싶었고, init=/path/to/the/vm 정도를 빼면 이게 가장 적은 노력으로 거기에 도달하는 방법처럼 보였음. 하지만 그 방식은 내가 진짜 원하는 것, 즉 하드웨어 드라이버와 TCP 스택을 VM 언어 안에 두는 것을 주지는 못함
    • 곧 돌릴 수 있는 Linux 애플리케이션의 부분집합이 있을 수도 있지 않을까? 프록시, NFS, 일부 데이터베이스 서버, HTTP 서버, 방화벽 같은 것들
      유용해지려면 Steam, LibreOffice, Firefox까지 돌릴 필요는 없다고 봄. 일반적인 서버나 마이크로서비스 아키텍처의 많은 구성요소는 하는 일이 비교적 단순하고, 안전하고 단순한 커널에서 꽤 큰 이점을 얻을 수 있을 것 같음

  • Rust로 만든 단일 커널이고 Linux ABI 호환성을 목표로 했던 Kerla도 있음. 다만 몇 년째 휴면 상태인 듯함
    [1] https://news.ycombinator.com/item?id=28986229

    • 아직 살아 있는 Redox OS도 있음: https://www.redox-os.org/
      마이크로커널 설계이고, 아마 조금 더 성숙했을 것임. MIT 라이선스라 코드 공유 여지도 있어 보임

  • “Rust로 되어 있다는 이유만으로도, 실력 있는 해커가 뭔가 찾을 수 있는지” 보려면 보안/침투 테스트/퍼징을 해보면 재미있을 듯함

    • Rust가 모든 것을 막아주지는 못함. 게다가 unsafe 코드도 많음
      퍼징 테스트나 침투 테스트를 하면 문제가 많이 드러날 거라고 100% 확신함. 아직 거기에 시간을 쓸 여유가 없었음

  • 지금은 중단된 Kerla 프로젝트에서 이미 시도했던 일 같음

  • 재미있는 프로젝트처럼 들림. 다만 C를 쓰는 단점과 OS 개발의 어려움은 대부분 디버깅 쪽에 있다고 봄
    Rust로 바꾸면서 특정 종류의 메모리 오류는 사라졌겠지만, 디버깅은 여전히 고통스러운가? 아니면 이전보다 줄어서 견딜 만해졌는지 궁금함

    • 메모리와 동시성 문제가 많이 사라졌음
      디버깅은 여전히 고통스럽지만, 예전보다는 훨씬 덜함
      예를 들어 뮤텍스를 쓰는 걸 깜빡할 가능성은 크지 않음. 컴파일러가 오류로 알려주기 때문임
      그렇다고 만능은 아니고, 교착 상태 같은 문제는 여전히 있음. 특히 인터럽션이 끼면 그렇다
      예를 들어 뮤텍스를 잠갔는데 인터럽션이 발생하면, 그 뮤텍스를 잠근 코드는 인터럽션이 끝날 때까지 멈춤. 그런데 인터럽션 처리 코드가 같은 뮤텍스를 잠그려 하면 교착 상태가 생기고, 타입 시스템은 이런 문제를 도와줄 수 없음
      해결책은 뮤텍스가 잠긴 동안 인터럽션 처리를 비활성화하는 것이지만, 컴파일러가 이를 강제할 수는 없음

  • 약간 딴길이지만, 작성자가 기여 영상에 쓴 Gource가 마음에 듦
    전에는 본 적이 없었는데 몇 년 전에 비슷한 걸 만들어보려는 아이디어가 있었음. 역시 완전히 새로운 아이디어는 없는 듯함

  • 특히 학습 목적이라면 커널을 직접 만드는 것이 정말 마음에 듦. 커널과 OS 전반을 이해하는 데 어떤 자료를 썼는지 궁금함

  • Theseus OS가 안 나온 게 의외임. Rust로 처음부터 만든 작업 중인 OS이고, Rust 컴파일러의 메모리 안전성 보장을 이용해 기존 OS라면 조심스럽게 배관해야 하는 많은 것들을 자동으로 제공함
    예를 들어 단일 권한 수준, 단일 주소 공간 구조인데도 안전함. OS의 모든 부분이 핫플러그 가능함
    단점은 네이티브 코드는 모두 Rust여야 한다는 점인데, 작년에 WASM 런타임이 구현됐음. 3년 전 관련 스레드:
    https://news.ycombinator.com/item?id=25741729

  • ft_penguin 프로젝트를 감당할 만큼 미친 사람이 있을 줄은 몰랐음. 아직 그 이름이 맞는지 모르겠지만, 솔직히 정말 잘했음
    7년 전 학교에 있을 때는 필요한 시간에 비해 보상이 가장 나쁜 프로젝트 중 하나라고 생각했음
    처음에는 친구와 같이 시작했는지, Rust로 다시 쓰기 전에는 어땠는지 궁금함. 동시에 다른 프로젝트도 했는지도 궁금함
    코드를 보니 재미있었던 기억이 나서, 이제 DevOps 일을 그만두고 원래 하려던 임베디드나 다른 저수준 작업을 하고 싶어짐

답변달기