1P by GN⁺ | ★ favorite | 댓글 1개
  • seL4는 보안·안전이 중요한 임베디드 및 사이버-물리 시스템을 겨냥한 OS 마이크로커널로, 하드웨어 자원을 격리·다중화하지만 완전한 범용 OS는 아님
  • 커널 모드 코드를 약 10 kSLOC로 줄여 TCB와 공격 표면을 축소하고, 파일 시스템·네트워크·드라이버 같은 OS 서비스는 사용자 모드로 밀어냄
  • 코드 수준 형식 검증을 갖춘 세계 최초 OS 커널이며, 올바르게 구성된 시스템에서는 기밀성·무결성·가용성 같은 보안 속성까지 커널이 보장함
  • capability 기반 접근 제어, WCET 분석, 혼합 중요도 실시간 시스템 지원, 하이퍼바이저 기능을 조합해 세밀한 격리와 실시간성을 함께 다룸
  • seL4 API는 매우 낮은 수준이라 복잡한 시스템은 직접 만들기 어렵고, 정적 아키텍처가 맞는 경우 Microkit 같은 프레임워크를 쓰는 방식이 현실적임

seL4가 맡는 범위

  • seL4는 운영체제의 낮은 수준 핵심부인 마이크로커널임
    • OS는 프로세서의 더 높은 권한 실행 모드인 커널 모드에서 하드웨어와 자원을 제어함
    • 애플리케이션은 사용자 모드에서 실행되며, OS가 허용한 방식으로만 하드웨어에 접근함
  • 마이크로커널은 높은 권한에서 실행되는 코드를 최소화한 OS 핵심부임
    • seL4는 1990년대 중반까지 거슬러 올라가는 L4 마이크로커널 계열에 속함
    • seL4는 seLinux와 관련 없음
  • seL4는 완전한 OS가 아니라 하드웨어 자원을 안전하게 다중화하고 격리하는 낮은 수준 커널임
    • 파일 시스템, 네트워크 스택, 디바이스 드라이버 같은 일반 OS 서비스는 커널 안에 있지 않음
    • 이런 서비스는 사용자 모드 프로그램으로 제공되어야 함

마이크로커널 구조와 공격 표면 축소

  • 리눅스 같은 모놀리식 커널은 파일 저장, 네트워킹 같은 OS 서비스를 커널 모드 코드로 제공함
    • 커널 모드 코드는 시스템 자원에 제한 없이 접근할 수 있어, 버그가 권한 상승이나 임의 코드 실행으로 이어지면 전체 시스템이 손상될 수 있음
    • 리눅스 커널은 약 20 MSLOC 규모이며, 수만 개의 버그가 있을 수 있다고 추정됨
  • seL4 같은 잘 설계된 마이크로커널은 커널 모드 코드를 약 10 kSLOC 수준으로 줄임
    • 이는 리눅스 커널보다 세 자릿수 규모로 작음
    • TCB가 줄어들면서 공격 표면도 함께 줄어듦
  • 대부분의 OS 서비스는 커널 밖으로 빠지고, 마이크로커널은 하드웨어 주변의 얇은 래퍼처럼 동작함
    • 핵심 제공 기능은 프로그램 간 격리와 안전한 호출 메커니즘임
    • 서비스는 커널 안이 아니라 별도 샌드박스에서 실행되는 사용자 모드 프로그램이 됨
  • 알려진 리눅스 침해 사례 중 치명적 사례를 분석한 연구에서, 마이크로커널 설계는 29% 를 완전히 제거하고 추가 55% 를 더 이상 치명적으로 분류되지 않을 정도로 완화할 수 있었음

PPC, capability, 세밀한 권한 제어

  • seL4는 보호된 프로시저 호출(PPC) 메커니즘을 제공함
    • 역사적 이유로 IPC라는 용어가 남아 있지만, IPC라는 표현은 오해를 낳아 나쁜 설계로 이어질 수 있음
    • PPC는 한 프로그램이 다른 샌드박스에 있는 프로그램의 함수를 안전하게 호출하게 함
  • 마이크로커널은 PPC에서 입력과 출력을 전달하고 인터페이스를 강제함
    • 원격 함수는 내보낸 진입점에서만 호출될 수 있음
    • 적절한 capability를 받은 명시적으로 허가된 클라이언트만 호출 가능함
  • capability는 시스템의 특정 자원에 접근할 수 있게 하는 접근 토큰임
    • 어떤 엔티티가 어떤 자원에 접근할 수 있는지 매우 세밀하게 제어함
    • 최소 권한 원칙 또는 최소 권한성 원칙(POLA)을 지원함
  • 리눅스나 Windows 같은 주류 시스템의 접근 제어 방식으로는 이런 수준의 최소 권한 달성이 불가능함
  • seL4는 capability 기반이면서 형식 검증된 세계 유일의 OS로, 이 조합 덕분에 세계에서 가장 안전한 OS라는 방어 가능한 주장을 갖는다고 평가됨

형식 검증과 보안 보장

  • seL4는 구현 정확성에 대한 형식적·수학적·기계 검증된 증명을 제공함
    • 이 증명은 커널이 명세와 관련해 매우 강한 의미에서 “버그 없음”을 뜻함
    • seL4는 코드 수준에서 이런 증명을 갖춘 세계 최초 OS 커널임
  • 구현 정확성 외에도 seL4는 보안 강제에 대한 추가 증명을 제공함
    • 올바르게 구성된 seL4 기반 시스템에서 커널은 기밀성, 무결성, 가용성을 보장함
  • 검증 체인은 seL4의 핵심 차별점임
    • 보안·안전 중요 시스템에서 커널이 신뢰 기반이 되려면 구현과 보안 속성에 대한 강한 보증이 필요함

실시간성과 혼합 중요도 시스템

  • seL4는 최악 실행 시간(WCET)에 대한 완전하고 건전한 분석을 거친 OS 커널임
    • 커널이 적절히 구성되면 모든 커널 연산은 시간상 경계가 있음
    • 그 경계도 알려져 있음
  • 이런 특성은 하드 실시간 시스템 구축의 전제 조건임
    • 엄격히 제한된 시간 안에 이벤트에 반응하지 못하면 치명적인 시스템을 대상으로 함
  • seL4는 혼합 중요도 실시간 시스템(MCS)도 지원함
    • 신뢰도가 낮은 코드가 같은 플랫폼에서 함께 실행되더라도 중요한 활동의 시간성을 보장해야 하는 환경을 대상으로 함
    • 기존 MCS OS가 쓰는 엄격하고 유연하지 않은 시간·공간 파티셔닝과 달리, seL4는 자원 활용을 유지하는 유연한 모델을 제공함

하이퍼바이저로 쓰는 seL4

  • seL4는 마이크로커널이면서 하이퍼바이저이기도 함
    • seL4 위에서 가상 머신을 실행할 수 있음
    • 가상 머신 안에서는 Linux 같은 일반 게스트 OS를 실행할 수 있음
  • 게스트와 애플리케이션은 seL4가 강제하는 통신 채널에 따라 서로 통신할 수 있음
    • 네이티브 애플리케이션과도 통신 가능함
  • Linux VM을 시스템 서비스 제공 수단으로 활용할 수 있음
    • 예시 구성에서는 별도 VM에서 실행되는 여러 Linux 인스턴스로부터 네트워킹과 스토리지 같은 서비스를 빌려옴

seL4 위에서 시스템을 만드는 방법

  • seL4 API는 다른 마이크로커널과 비교해도 매우 낮은 수준임
    • 하드웨어를 안전하게 관리하는 데 필요한 최소 추상화만 제공함
    • seL4는 “운영체제의 어셈블리어”에 비유됨
  • 복잡한 시스템을 seL4 위에 직접 만드는 방식은 적절하지 않음
    • 더 높은 수준의 프레임워크가 서비스 구현 코드에 집중하게 하고, 하드웨어 복잡성과 시스템 통합을 자동화해야 함
  • seL4에는 세 가지 주요 오픈소스 컴포넌트 프레임워크가 있음
    • Microkit: protection domain 중심의 소수 추상화로 seL4 API를 단순화하고, 별도 컴파일 모듈과 커널 바이너리를 통합해 부팅 가능한 이미지를 만드는 SDK를 제공함
    • CAmkES: Microkit의 전신이며 정적 아키텍처 시스템을 위한 컴포넌트 프레임워크지만, SDK가 없어 빌드 과정이 더 불편하고 오버헤드가 큼
    • Genode: 여러 마이크로커널을 지원하고 x86 플랫폼용 서비스와 드라이버가 풍부하며 정적 아키텍처를 강제하지 않지만, seL4의 모든 보안·안전 기능을 활용하지 못하고 보증 스토리가 없음
  • 정적 시스템 아키텍처가 요구사항에 맞는 한, seL4 기반 시스템 구축에는 Microkit이 권장됨
    • 정적 아키텍처는 모듈 집합과 통신 구조를 시스템 구성 시점에 정의하는 모델임
    • 이 모델은 자동차와 항공기 같은 복잡한 사이버-물리 시스템을 포함해 대부분의 임베디드 시스템 요구에 맞는 것으로 봄

댓글과 토론

Hacker News 의견들
  • seL4 자체는 오래된 이야기인데, 마이크로커널을 넘어 새로 형식 검증된 계층이나 구성요소가 추가됐는지 궁금함
    또 ‘증명’이라는 단어를 보면 감정적으로 과부하가 와서 사고가 멈추는 사람들도 있어 보임. 형식 검증은 안전한 IT라는 무한한 문제를 해결하는 만병통치약도, 완벽무결한 소프트웨어를 만들어내는 방법도 아님
    이해하기로는 특정 조건에서 특정 요구사항을 만족한다는 증명이고, 그 요구사항과 조건은 꽤 좁을 수 있으며, 명세 밖의 기능과 조건에 대해서는 아무 말도 하지 않는다는 뜻인데 대략 맞는지 궁금함
    실무적으로 보안 전문가는 ‘형식 검증된 소프트웨어’를 보면 무엇을 기대하는지도 궁금함. seL4가 만족하는 명세가 무엇인지가 여기서 핵심 정보 아닌가 싶음

    • 여러 결함이 없다고 형식 검증됐어도 seL4가 메모리 손상 결함에 면역인 것은 아니었음. 몇 년 전 메모리 손상 결함이 발견됐고, 이를 고친 커밋과 seL4 증명을 수정한 PR이 공개돼 있음
      https://github.com/seL4/seL4/pull/243
      https://github.com/seL4/l4v/pull/453
      이슈 추적기에도 메모리 관련 버그가 여럿 있음
      https://github.com/seL4/seL4/issues?q=is%3Aissue%20label%3Ab...
      흥미롭게도 메모리의 “register clobbering”을 고친 PR은 bug 라벨이 붙지 않아 “bug”로 필터링하면 나오지 않음. 예전에는 증명 덕분에 seL4가 이런 문제에 면역이라고 생각했지만, 이를 보고 나서는 증명이 커뮤니티가 믿게 된 것만큼 포괄적이지 않다고 보게 됨. 그래도 seL4는 여전히 매우 인상적인 소프트웨어임
      질문에 답하자면 seL4가 만족하는 명세는 GitHub에 공개돼 있음
      https://github.com/seL4/l4v
    • 형식 검증된 계층이나 구성요소는 계속 추가되고 있음. 최근에는 RISC-V 등 새 아키텍처 지원, 혼합 중요도 스케줄링, Microkit, Device Driver Framework가 들어감
      혼합 중요도 스케줄링은 CPU 시간에 대한 capability 기반 접근, 스레드 실행 상한 제한, 고중요도 작업 우선순위와 자원 접근 보장, 호출자가 기부한 스케줄링 시간으로 도는 “passive servers”를 제공함
      Microkit은 seL4 위에서 실제 시스템을 훨씬 쉽게 만들게 해주는 검증된 추상화 계층이고, Device Driver Framework는 seL4에서 고성능 입출력을 위한 장치 드라이버 템플릿, 제어/데이터 평면 구현, 드라이버 작성 및 장치 가상화 도구임
      형식 검증은 특정 조건에서 특정 요구사항이 성립함을 보장할 수 있음. 일반적으로 그런 요구사항과 조건이 좁을 수 있다는 건 맞지만, seL4 자체에는 커널에 기대할 만한 넓은 범위의 속성을 다루는 증명이 많이 있고, 그 보장은 매우 약한 가정 아래에서도 성립함. C 컴파일러의 정확성도 가정하지 않고, 컴파일러 출력물을 보고 컴파일된 바이너리가 요구된 C 의미론에 맞게 동작함을 증명하는 별도 도구가 있음
      seL4가 만족하는 요구사항에는 seL4 커널의 바이너리 코드가 추상 명세에 기술된 동작을 정확히 구현하고 그 이상은 하지 않는다는 것이 포함됨. 버퍼 오버플로, 메모리 누수, 포인터 오류, 널 포인터 역참조, C 코드의 정의되지 않은 동작, 명세에 열거된 명시적 방법 외의 커널 종료 등이 없음
      명세와 seL4 바이너리는 무결성기밀성 보안 속성도 만족함. 무결성은 프로세스가 명시적 권한이 없는 데이터를 바꿀 방법이 전혀 없다는 뜻이고, 기밀성은 권한 없는 데이터를 어떤 방식으로도 읽을 수 없다는 뜻임. 특정 부채널을 통해 간접적으로 데이터를 추론할 수 없다는 것까지 보임. 보안 외에도 예상 최악 실행 시간 보장과 스케줄링 속성도 충족됨
    • seL4 개발자들은 몇 년째 자금난에 시달리고 있음. 작업 대부분은 원격 조종 드론을 위한 DARPA 연구였고, 미군은 해킹당하지 않는 드론을 매우 원함
      현재 작업은 더 넓은 도입을 지향하는 LionsOS 쪽임: https://lionsos.org/
    • 예를 들면 버퍼 오버플로, 널 포인터 예외, 해제 후 사용 등이 없음. ARM과 RISCV64에서는 바이너리에 대해 기능적 정확성이 증명됐기 때문에 C 컴파일러조차 신뢰할 필요가 없음. 기능적 정확성 외에도 더 많은 증명이 있음
      https://docs.sel4.systems/projects/sel4/frequently-asked-que...
    • https://github.com/auxoncorp/ferros
      자원, 하드웨어 접근, capability를 컴파일 시점에 추적하기 위해 타입 수준 프로그래밍을 많이 씀. 런타임에서 문제를 발견하고 디버깅하는 것이 너무 최악이라, 기반 커널 보장의 일부를 컴파일러 쪽으로 끌어올리려는 시도임
  • 게스트 단일체 커널을 올리는 마이크로커널 호스트를 좋아해서, 서버들은 FreeBSD VM의 안전 계층과 백업으로 seL4를 돌리고 있고 그 안에서 renderfarm, BEAM 클러스터, Jenkins용 jail을 사용 중임
    아쉬운 건 DragonflyBSD의 스레딩과 프로세스 내부 커널, 즉 하이브리드 커널 설계를 위해 ARM 포트가 없다는 것임. 꿈은 128코어 Ampere Altra에서 OpenMoonRay를 더 효율적으로 돌리는 것임

    • 서버에서 seL4를 어떻게 쓰는지 더 자세히 알고 싶음. 그리고 이게 프로덕션 상용 서버인지도 궁금함
    • 그 구성은 긴 글로 읽으면 꽤 흥미로울 것 같음
  • 이제는 마이크로커널 찬반 논쟁 자체가 큰 의미가 없어지는 듯함. 권한 있는 서비스에 빠르고 효율적이며 안전하게 접근하는 유일한 방법은 하드웨어 완화책이고, 소프트웨어가 할 수 있는 일에는 한계가 있음
    80286과 80386의 차이와 비슷함. 후자는 전자가 갖지 못한 진짜 멀티태스킹용 하드웨어 지원을 추가했음. 그 뒤로 하이퍼바이저를 가능하게 한 것 같은 하드웨어 수준 보호 메커니즘이 계속 늘어남
    특히 Apple은 SoC에 커널, 드라이버, 구성요소를 칩 수준에서 보호하고 실행 중인 스레드와 포인터 사용 시 권한을 강제하는 기능을 많이 넣고 있음. https://support.apple.com/guide/security/operating-system-in...
    그렇다고 OS가 뚫을 수 없다는 뜻은 아니지만, 권한을 소프트웨어만으로 관리하는 전략보다는 훨씬 효과적임. 이런 기능이나 비슷한 것을 활용하면 커널 구조는 더 이상 그리 중요하지 않은 것처럼 보이는데, 내가 틀린 건지 궁금함

    • 틀렸음. OS 연구 영역에는 아직 할 일이 많고, 새 하드웨어에 대한 소프트웨어 인터페이스와 API가 필요함
      더 조합 가능한 마이크로/하이브리드 시스템에서도 배울 점이 많음. 예를 들어 Plan 9은 단일 프로토콜인 9P로 시스템의 모든 객체를 사용자 공간에 제공하는 훌륭한 하이브리드 시스템임. IP나 TLS처럼 시스템 호출 오버헤드를 피하려고 일부는 커널 안에 있으므로 하이브리드임
      또 흥미로운 설계는 커널 내부 드라이버가 대체로 하드웨어 로직에 대한 9P 인터페이스 역할만 하는 최소 형태라는 점임. 이렇게 하면 포인터나 레코드 같은 기계 객체를 탐색 가능한 파일로 바꾸고, 표준 Unix 권한으로 그 파일을 보호하며, 네트워크를 통해 구성요소를 여러 기계에 쉽게 분산할 수 있음. 그 결과 드라이버 로직을 안전하게 사용자 공간 프로그램으로 밀어낼 수 있음
      9P는 네트워크와 아키텍처에 투명해서 Arm, x86, mips 등 여러 기계에서 바로 함께 작업할 수 있음. Plan 9에서 Linux/Unix나 Windows로 돌아가면 슬프고 답답함. 유연성이 거의 화성암 수준이고, 같은 일인 파일/객체 제공을 하는 수많은 프로토콜로 기능들이 서로 호환되지 않게 덧붙여져 있음
    • 마이크로커널의 효용은 하드웨어/소프트웨어 공동 설계와는 별개의 축임
      실용적인 공학 관점에서 단일체 커널은 더 빠르고 쉽고 자원도 더 많았으며, 보안은 C로 가능한 수준, 즉 최선의 노력과 수많은 버그였음. 그 난장판을 완화하려고 많은 하드웨어가 도입됐음. 하지만 SeL4라면 프로세스 간 격리와 루트 수준 익스플로잇 부재에 대한 신뢰도가 매우 높기 때문에 이론적으로 보안 보조 프로세서가 필요 없을 수 있음. 그러니 하드웨어/소프트웨어 공동 설계는 중요함
      다만 SeL4 팀도 하드웨어의 부채널을 제거하는 데 많은 공학 자원을 써야 했음. 실제 세계는 물리 시뮬레이션을 신경 쓰지 않기 때문에 하드웨어도 결함이 있음
      여기서 마이크로커널의 장점은 형식 검증이 다룰 수 있을 만큼 작다는 것임. 증명 자체는 커널 크기의 10배임. SeL4의 문맥 전환은 Linux보다 한 자릿수 배 빠르므로 성능 영향은 무시할 만해야 함. 하지만 마법처럼 수백만 줄짜리 단일체 커널을 검증할 수 있다면, 문맥 전환을 하지 않는 쪽이 여전히 더 빠름. 실제로 SeL4 팀은 스케줄러를 사용자 공간으로 옮기려 했지만 성능 비용이 너무 커서 커널 안에 남기고 증명 부담에 추가했음
    • 80286과 80386 비교는 좋은 비유인지 모르겠음. 286도 보호 모드에서 진짜 멀티태스킹을 지원했고, 여러 비-DOS 운영체제에서 쓰였음. 386이 추가한 것 중 하나는 가상 8086 모드로, 하드웨어에 직접 접근하던 기존 실모드 DOS 애플리케이션을 멀티태스킹할 수 있게 한 것임
    • 그 설명은 맞지 않아 보임. 강한 하드웨어 보호가 있어도 Linux의 신뢰 컴퓨팅 기반이 마이크로커널과 어떻게 비교 가능하겠음? 똑같은 보호 도메인을 재현하지 않는 한 Linux에는 더 많은 취약점이 남음
      오히려 하드웨어의 주된 역할은 효율성을 높이는 것임. 예를 들어 요즘 마이크로커널은 이미 MMU 같은 하드웨어를 잘 활용하기 때문에 꽤 견고함. 그다음 마이크로커널의 작은 신뢰 컴퓨팅 기반이 커널에 신뢰성을 주고, 커널과 하드웨어가 함께 튼튼한 기반을 만듦
      결국 하드웨어로 어느 정도까지 “반칙”을 허용할지의 문제지만, 전반적으로 마이크로커널이 보호 기능을 더 잘 활용함. 아니면 엑소커널을 봐도 됨
  • https://genode.org/index
    seL4 지원이 있는 운영체제임

    • Genode의 주목할 만한 사용처가 있는지 궁금함
  • 지역 OWASP 챕터에서 SeL4 발표를 한 적이 있음. 자료를 찾아볼 수 있을지 모르겠음
    이 프로젝트는 정말 잘 만든 물건이지만, 특히 범용 컴퓨팅에서는 Linux 대체재로 보기는 망설여짐. 그렇다고 마이크로커널이 범용에 전반적으로 나쁘다는 뜻은 아님. RedoxOS는 최근 어느 정도 진전이 있어 보이고 Rust로 작성된 마이크로커널을 사용함

    • 항상 문제는 “얼마나 큰 범위의 대체를 말하느냐”임. Redox는 POSIX 상호운용성을 잘 유지하려는 듯하고, 이는 자연스럽게 설계 결정에 영향을 줌. 기술적 능력을 갖는 것과 성공하는 것 사이에는 큰 차이도 있음
      그래도 Redox가 성공한다면 그것만으로도 좋은 진전임. seL4는 이런 특성이 더 극단적임. 기술적 장점은 뛰어나지만, 지금까지도 그렇고 앞으로도 아마 ‘다음 대세’가 되기 위한 무언가를 갖추지는 못할 것 같음. 정치적 고려를 빼면 마이크로커널은 성공할 것이고, 그래야 마땅하다고 봄
    • Linux 대체 가능성은 시나리오에 따라 다름. 물론 Linux가 다루기 쉽지만, 반대로 seL4만 만족할 수 있는 요구사항도 있음
      seL4가 실제로 유용하려면 그 위에 필요한 것이 많음. 다행히 그 부분에도 오픈소스 작업이 많이 진행됐고, 몇 년 전보다 훨씬 나은 위치에 있음
      정적인 시나리오에는 LionsOS[0]가 있고 이미 꽤 쓸 만함
      동적인 시나리오에는 Provably Secure, General-Purpose Operating System[1]이 있는데 아직 초기 단계임
      둘 다 seL4 웹사이트에 연결된 trustworthy systems의 Projects 페이지[2]에서 찾을 수 있음
      [0] https://trustworthy.systems/projects/LionsOS/
      [1] https://trustworthy.systems/projects/smos/
      [2] https://trustworthy.systems/projects/
  • 이 커널 위에 올라가는 OS도 보안 보장이 성립하려면 형식 검증돼야 하는지 궁금함

    • 커널이 제공하는 보장은 그 위에서 도는 비권한 프로세스가 깨뜨릴 수 없음
      물론 커널만으로는 그다지 유용하지 않으므로, 커널 위에서 실행되는 드라이버, 파일시스템 서버, 기타 서비스의 설계는 여전히 중요함
      Linux를 포함한 대부분의 다른 시스템은 근본 수준에서 결함이 있지만, seL4는 실제로 안전하고 신뢰할 수 있는 시스템을 만들 수 있게 해준다는 점도 중요함
    • 아님. 장점은 커널이 격리를 보장하므로 커널과 프로세스를 신뢰할 필요가 없다는 것임
      그래서 Linux 커널을 고보안 프로세스 옆에서 실행하면서도, 허용된 IPC를 제외하면 서로 격리된다는 보장을 가질 수 있음
    • 아님
      하지만 한계가 있음. DMA는 꺼야 하고, 드라이버도 형식 검증된 것만 써야 함
      seL4의 멀티코어 커널은 아직 검증되지 않았다는 점도 중요함
    • 절대적인 의미에서는 그렇다고 볼 수 있음. 실용적인 수준에서는 논문 7.2절에서 부분적인 답을 찾을 수 있음
  • Drew DeVault의 Helios Microkernel도 볼 만함. SeL4 기반이라고 함
    https://ares-os.org/docs/helios/

    • “기반”과 “영감을 받음” 사이에는 의미 있는 차이가 있고, Helios는 후자에 가까워 보임
  • Karlsruhe 대학에서는 L4가 인기가 있었음. 자세히 들여다본 적은 없지만, 실용적으로 유용한 것을 만들기보다는 이론적 아이디어를 시험하는 데 주로 관심 있는 프로젝트처럼 보였음
    그게 20년 전이었고, 내가 보기에는 지금도 크게 달라지지 않았음. 빠르게 검색해보니 그 위에 OS를 만들려는 시도들이 있는 듯하지만, 실제 사용보다는 개념 증명에 더 가까워 보임

    • https://en.wikipedia.org/wiki/L4_microkernel_family를 보면 L4가 여러 곳에서 쓰였고, 주로 임베디드 환경에서 사용된 듯함
      “OKL4 출하량은 2012년 초 15억 개를 넘었고, 대부분 Qualcomm 무선 모뎀 칩이었다. 다른 배포처에는 자동차 인포테인먼트 시스템이 포함된다”
      “A7부터 시작하는 Apple A 시리즈 프로세서에는 L4 운영체제를 실행하는 Secure Enclave 보조 프로세서가 들어 있으며, 이 OS는 2006년 NICTA에서 개발한 L4-embedded 커널 기반의 sepOS다. 그 결과 L4는 Apple silicon을 탑재한 Mac을 포함해 모든 현대 Apple 기기에 실린다”
    • Jochen Liedtke는 1999년에 Karlsruhe 교수가 됐지만 안타깝게도 2001년에 얼마 지나지 않아 세상을 떠났음. 후임자인 Bellosa가 아직 L4 연구를 하는지는 모르겠음. L4Ka 프로젝트가 있었지만 완료된 것으로 보임. Bellosa의 학부 운영체제 강의에서는 커리큘럼에 포함되지 않음
      Bellosa의 동문인 Rittinghaus는 HN에도 몇 번 소개된 Unikraft[0]에 관여하고 있고, 유니커널 기술을 사용함
      [0] https://unikraft.org/
    • iPhone에는 L4 변종이 쓰임
      “Secure Enclave Processor는 Apple이 맞춤화한 L4 마이크로커널 버전을 실행한다”
      https://support.apple.com/de-at/guide/security/sec59b0b31ff/...
    • 오픈소스 파생판인 L4Re는 모든 id.X Volkswagen 차량의 중앙 “icas1” ECU에서 실행되며, Linux와 다른 게스트를 싣고 있음
      https://www.kernkonzept.com/kk_events/elektrobit-advances-au...
      내가 보기에는 L4Re 커널도 Elektrobit Safe Linux의 일부임
    • Karlsruhe 팀이 L4Ka, 특히 Pistachio에서 한 작업과 방향을 좋아함. 설계가 깔끔하고 단순하며 이해하기 쉬웠음
      졸업 논문으로 Pistachio 기반 OS를 만들었음. Karlsruhe에서 공부했다면 아마 OS 연구로 갔을 것 같다고 늘 생각했음
  • 나도 운영체제 설계 아이디어가 있었고, 고려했던 capability는 seL4와 같은 중간 개입과 위임 기능을 사용했음. 거기에 적힌 것 외에도 장점이 있음. 예를 들어 오디오에 필터를 적용하거나, 네트워크 투명성을 구현하기 위해 프록시 capability를 쓸 수 있음
    실시간 기능은 선택적 구현으로 허용할 수 있다고 생각했음. 내 아이디어는 단일 구현이 아니라 명세에 가까웠음
    또 원했던 기능은 모든 프로그램이 입출력을 제외하면 결정론적으로 동작하는 것임. 입출력 없이는 날짜/시간이나 프로그램 실행 시간을 알 수 없고, 프로세서 기능도 확인할 수 없음. 하드웨어가 지원하지 않는 기능을 쓰면 운영체제가 에뮬레이션할 수는 있음
    이를 구현하려고 하드웨어 지원과 소프트웨어 지원을 섞어 쓸 생각이었음. 문서에는 하드웨어로 구현된 capability에 대한 공격 메모가 있지만, 참조 문서를 갖고 있지 않아 그 공격이 내가 생각한 방식에도 적용되는지는 모름

  • 보안 관점에서는 Linux 커널의 KVM과 같은 실패를 보이는 듯함. 하이퍼바이저가 ring 0에 있으면 한 VM에서 다른 VM이나 호스트 자체로 탈출할 위험이 있음
    그 위험을 어떻게 완화하는지 궁금함

    • seL4의 가상화 지원에서는 VM 예외가 메시지로 바뀌고, 비권한 모드에서 실행되는 작업인 VMM이 이를 처리함
      VMM은 VM 자체보다 더 많은 capability를 갖지 않으므로, 학술적 의미를 제외하면 VM 탈출은 가치가 없음
      원문 PDF 8~10쪽을 보면 됨