흥미로운 접근법이라는 생각, 성공을 바라는 입장임. 하지만 여전히 의구심이 남음. 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 구분 성질을 잘 살린 프로젝트라는 점에서 흥미와 기대감이 큼
정말 대단한 시도라고 생각, 작성자가 이 스레드에 있다는 점도 감동. 어느 수준까지 usable한지 궁금함, 일부 제한적 환경에서라도 서버 이미지를 빌드해서 실험하고 싶음
Asterinas는 아직 상대적으로 새로운 커널이라 범용 사용에는 다듬어야 할 점이 많음. 하지만 실제로 효율적이고 신뢰할 만한 실서비스 운영을 목표로 한다면 그 격차는 그리 크지 않고, 1년 이내에 목표 도달 가능성 있음. 현재 Linux 네임스페이스, cgroups 같은 핵심 기능 구현과 최초의 Asterinas 기반 배포판 작업이 진행 중. 초기 목표는 Confidential VMs의 게스트 OS로 Asterinas를 활용하는 것이며, 메모리 안전성과 작은 TCB 덕분에 보안 측면에서 Linux보다 명확한 강점이 있음
마이크로커널 IPC가 느려서 인기가 적다는 설명을 보며, 기술적으로 뛰어난 사람들도 실제 채택 이유와 그 과정에서 오해를 하는 것 같아 안심
그렇다면 정확히 어떤 점에서 잘못 해석되고 있는지 알려줘야 모두에게 도움이 될 것임
라이선스가 MPL인데, 개인적으로는 더 나은 라이선스(GPLv3 등)도 있다고 생각함
문서에서 MPL을 선택한 이유를 직접 설명하고 있음. 내가 좋아하는 선택은 아니지만 이유는 납득 가능함
정말 괜찮은 아이디어라는 생각. 이미 많은 소프트웨어가 구축돼 있고, 대안적 기반이 있으면 기술 외적인 이유들로도 큰 이점이나 선택지가 생길 수 있음. kFreeBSD, GNU/Hurd가 떠오름
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한지 궁금함, 일부 제한적 환경에서라도 서버 이미지를 빌드해서 실험하고 싶음
마이크로커널 IPC가 느려서 인기가 적다는 설명을 보며, 기술적으로 뛰어난 사람들도 실제 채택 이유와 그 과정에서 오해를 하는 것 같아 안심
라이선스가 MPL인데, 개인적으로는 더 나은 라이선스(GPLv3 등)도 있다고 생각함
정말 괜찮은 아이디어라는 생각. 이미 많은 소프트웨어가 구축돼 있고, 대안적 기반이 있으면 기술 외적인 이유들로도 큰 이점이나 선택지가 생길 수 있음. kFreeBSD, GNU/Hurd가 떠오름
이런 커널들은 뭐라고 불러야 할 지 고민. *nux?