마이크로커널

3. 특징

마이크로커널은 운영체제의 핵심 기능만 커널에 남기고, 나머지 서비스는 사용자 공간에서 실행하는 구조를 가진다. 이는 모듈화, 유지보수 용이성, 안정성 향상 등의 장점을 제공하지만, 프로세스 간 통신(IPC) 오버헤드로 인해 성능 저하 문제가 발생할 수 있다.^[13]

대부분의 주류 프로세서에서 서비스를 얻는 것은 모노리틱 커널 시스템보다 마이크로커널 기반 시스템에서 본질적으로 더 비싸다.^[13] 모놀리식 시스템에서는 단일 시스템 호출을 통해 서비스를 얻는데, 이는 두 번의 ''모드 전환'' (CPU 모드 변경)을 필요로 한다. 반면 마이크로커널 기반 시스템에서는 서버에 IPC 메시지를 보내고, 서버로부터 다른 IPC 메시지로 결과를 얻어야 한다. 이는 드라이버가 프로세스로 구현된 경우 컨텍스트 스위치를, 프로시저로 구현된 경우 함수 호출을 필요로 한다. 또한, 데이터를 서버로 전달하고 다시 가져오는 과정에서 추가적인 복사 오버헤드가 발생할 수 있지만, 모놀리식 시스템에서는 커널이 클라이언트의 버퍼에 있는 데이터에 직접 접근할 수 있다.^[51]

따라서 성능은 마이크로커널 시스템에서 잠재적인 문제로 간주된다. Mach 및 ChorusOS와 같은 1세대 마이크로커널의 경험은 이를 기반으로 하는 시스템의 성능이 매우 낮다는 것을 보여주었다.^[16] 그러나 요헨 리트케는 Mach의 성능 문제가 Mach의 과도한 캐시 점유율과 같은 좋지 않은 설계와 구현의 결과임을 보였다.^[17] 리트케는 자신의 L4 마이크로커널을 통해 신중한 설계와 구현, 특히 최소주의 원칙을 따름으로써 IPC 비용을 Mach에 비해 10배 이상 줄일 수 있음을 입증했다. L4의 IPC 성능은 다양한 아키텍처에서 여전히 최고 수준을 유지하고 있다.^[24][25][26]

이러한 결과는 1세대 마이크로커널 기반 시스템의 낮은 성능이 L4와 같은 2세대 커널을 대표하지 않는다는 것을 보여주지만, 마이크로커널 기반 시스템이 좋은 성능으로 구축될 수 있다는 완벽한 증거는 아니다. 모놀리식 Linux 서버를 L4로 포팅했을 때 네이티브 Linux에 비해 몇 퍼센트의 오버헤드만 발생한다는 것이 입증되었다.^[27] 그러나 그러한 단일 서버 시스템은 운영 체제 기능을 별도의 서버로 구조화하여 마이크로커널이 제공해야 하는 장점을 거의 또는 전혀 나타내지 않는다.

상업적인 다중 서버 시스템, 특히 실시간 시스템인 QNX와 Integrity가 존재한다. 이러한 다중 서버 시스템에 대해 모놀리식 시스템과의 성능에 대한 포괄적인 비교는 발표되지 않았다. 또한, 성능은 이러한 상업용 시스템의 가장 중요한 관심사가 아닌 것으로 보이며, 대신 안정적으로 빠른 인터럽트 처리 응답 시간(QNX)과 견고성을 위한 단순성에 중점을 둔다.

3. 1. 장점

• OS 개발 효율 향상 (기능 확장, 디버깅 등을 용이하게 수행)
• 시스템 전체를 멈추지 않고 커널 이외의 OS 업데이트를 수행할 수 있다.
• 필요한 기능만 제공하는 애플리케이션에 특화된 OS를 구축하기 쉬워진다.^[32]

3. 2. 단점

4. 핵심 구성 요소

마이크로커널은 운영 체제의 핵심 기능만을 제공하며, 주요 구성 요소는 다음과 같다:

• 메모리 관리: 주소 공간 관리 및 메모리 보호 기능을 제공한다.^[17]
• 프로세스 관리: 프로세스 생성, 스케줄링, 프로세스 간 통신(IPC) 기능을 제공한다.^[17]
• 하드웨어 추상화 계층 (HAL): 하드웨어 의존적인 부분을 추상화하여 이식성을 높인다. (요약에는 없지만 원문에 HAL에 대한 언급은 없다)

5. 프로세스 간 통신 (IPC)

프로세스 간 통신(IPC)은 서로 다른 프로세스가, 일반적으로 메시지 전달을 통해 서로 통신할 수 있게 해주는 메커니즘이다. 공유 메모리도 엄밀하게 정의하면 프로세스 간 통신 메커니즘의 일종이지만, 마이크로커널에서 IPC라고 하면 일반적으로 메시지 전달을 의미한다. IPC를 사용하면 운영 체제를 서버라고 하는 소규모 프로그램으로 구축할 수 있으며, 시스템의 다른 프로그램에서 IPC를 통해 이러한 서버를 호출하여 사용한다. 주변 하드웨어에 대한 대부분 또는 전부의 지원은 장치 드라이버, 네트워크 프로토콜 스택, 파일 시스템, 그래픽 등을 위한 서버를 사용하여 처리된다.

IPC에는 동기식과 비동기식이 있을 수 있다. 초기 마이크로커널은 일반적으로 동기 및 비동기 IPC를 모두 지원했지만 IPC 성능이 좋지 않았다. 요헨 리트케(Jochen Liedtke)는 이러한 성능 저하의 근본적인 이유가 IPC 메커니즘의 설계 및 구현에 있다고 가정했다. 그의 L4 마이크로커널에서 그는 IPC 비용을 규모의 차수만큼 낮추는 방법을 개척했다.^[15] 여기에는 전송 및 수신 작업을 모두 지원하는 IPC 시스템 호출, 모든 IPC의 동기화, 가능한 많은 데이터를 레지스터로 전달하는 것이 포함된다. 또한 리트케는 IPC 실행 중에 (불완전한) 컨텍스트 스위치가 발신자에서 수신자로 직접 수행되는 '직접 프로세스 전환' 개념을 도입했다. L4와 같이 메시지의 일부 또는 전부가 레지스터로 전달되는 경우, 이는 복사 없이 레지스터 내 메시지 부분을 전송한다. 또한 스케줄러 호출에 따른 오버헤드를 피할 수 있다. 이는 클라이언트가 서버를 호출하여 원격 프로시저 호출 (RPC) 유형 방식으로 IPC를 사용하는 일반적인 경우에 특히 유용하다. '지연 스케줄링'이라고 하는 또 다른 최적화는 IPC 중에 스레드를 차단하여 스케줄링 큐를 순회하는 것을 피하고, IPC 중에 차단된 스레드를 준비 큐에 둔다. 스케줄러가 호출되면 이러한 스레드를 적절한 대기 큐로 이동한다. 많은 경우에 스레드는 다음 스케줄러 호출 전에 차단 해제되므로 이 접근 방식은 상당한 작업을 절약한다. 유사한 접근 방식은 이후 QNX와 MINIX 3에서 채택되었다.

일련의 실험에서, 첸과 버샤드는 모놀리식 Ultrix의 메모리 명령당 사이클 (MCPI)을 사용자 공간에서 실행되는 마이크로커널 Mach와 4.3BSD 유닉스 서버의 MCPI와 비교했다. 그들의 결과는 높은 MCPI로 인해 Mach의 성능이 저조하다는 것을 설명하고, IPC만으로는 시스템 오버헤드의 많은 부분을 차지하지 않는다는 것을 보여주었으며, 이는 IPC에만 집중된 최적화가 제한적인 효과를 가질 것이라는 것을 시사한다.^[16] 리트케는 나중에 Ultrix와 Mach MCPI의 차이 대부분이 용량 캐시 미스에 의해 발생한다는 점을 관찰하고, 마이크로커널의 캐시 작업 집합을 대폭 줄이면 문제가 해결될 것이라고 결론을 내리면서 첸과 버샤드의 결과를 개선했다.^[17]

클라이언트-서버 시스템에서 대부분의 통신은 비동기 기본 요소를 사용하더라도 클라이언트가 서버를 호출한 다음 응답을 기다리는 일반적인 작업이므로 본질적으로 동기적이다. 또한 보다 효율적인 구현에 적합하므로 대부분의 마이크로커널은 일반적으로 L4의 선례를 따라 동기 IPC 기본 요소만 제공했다.

5. 1. 동기식 IPC

5. 2. 비동기식 IPC

6. 서버

마이크로커널에서 서버는 사용자 공간에서 실행되는 프로세스로, 특정 기능을 제공한다. 일반적인 서버로는 파일 시스템 서버, 장치 드라이버 서버, 네트워크 서버, 디스플레이 서버 등이 있다. 서버는 일반 애플리케이션처럼 개발 및 유지보수가 가능하다.^[20] 서버 오류 발생 시 해당 서버만 재시작하면 되므로, 시스템 전체 안정성이 향상된다.^[46]

마이크로커널 서버는 다른 데몬 프로그램과 유사하지만, 커널은 일부 서버에 물리 메모리 영역과 상호 작용할 수 있는 권한을 부여한다. 이를 통해 장치 드라이버가 하드웨어와 직접 상호 작용할 수 있다.

범용 마이크로커널의 기본 서버에는 파일 시스템 서버, 장치 드라이버 서버, 네트워킹 서버, 디스플레이 서버, 사용자 인터페이스 장치 서버가 포함된다. 이 서버 집합은 QNX에서 가져온 것으로, Unix 모놀리식 커널에서 제공하는 서비스와 거의 동일하다. 필요한 서버는 시스템 시작 시 시작되며, 일반 응용 프로그램에 파일, 네트워크 및 장치 액세스 등의 서비스를 제공한다. 서버가 사용자 응용 프로그램 환경에서 실행되므로, 서버 개발은 일반 응용 프로그램 개발과 유사하며, 커널 개발에 필요한 빌드 및 부팅 프로세스가 필요하지 않다.

서버에 오류가 발생해도 시스템 전체가 중단되지 않고, 해당 서버만 재시작하면 된다. 하지만 시스템 상태 일부가 손실될 수 있으므로, 응용 프로그램은 서버 오류에 대처해야 한다. 예를 들어, TCP/IP 연결을 담당하는 서버를 재시작하면 응용 프로그램은 연결이 끊기는 것을 경험하는데, 이는 네트워크 시스템에서 정상적으로 발생할 수 있는 장애이다. 다른 서비스의 경우, 응용 프로그램이 오류를 예상하지 못하면 코드 변경이 필요할 수 있다. QNX는 QNX High Availability Toolkit을 통해 재시작 기능을 제공한다.^[20]

ChorusOS와 같이 트랜잭션이나 복제 등의 데이터베이스 기술을 도입하여 전체 서버를 재시작 가능하게 만든 마이크로커널도 있다.

7. 장치 드라이버

장치 드라이버는 직접 메모리 접근(DMA)을 수행하는 경우가 많아, 커널 데이터 구조를 포함한 물리 메모리의 임의 위치에 쓰기 작업을 할 수 있다. 따라서 이러한 드라이버는 신뢰성이 높아야 한다. 하지만, 드라이버가 커널의 일부가 된다고 해서 본질적으로 더 신뢰할 수 있거나 덜 신뢰할 수 있는 것은 아니다.

사용자 공간에서 장치 드라이버를 실행하면 버그가 있는 드라이버(악의적인 드라이버는 제외)로 인한 시스템 안정성 문제를 줄일 수 있다. 드라이버 코드 자체의 메모리 접근 위반은 메모리 관리 하드웨어에 의해 감지될 수 있기 때문이다. 또한, DMA를 사용하지 않는 많은 장치는 사용자 공간에서 실행하여 신뢰할 수 없게 만들 수 있다. 최근에는 IOMMU를 탑재한 컴퓨터가 늘어나고 있으며, 이를 통해 장치의 물리적 메모리 접근을 제한할 수 있다.^[47] 이는 사용자 모드 드라이버를 신뢰할 수 없게 만드는 또 다른 방법이다.

사용자 모드 드라이버는 마이크로커널보다 먼저 등장했다. 1967년 미시간 터미널 시스템(MTS)은 사용자 공간 드라이버(파일 시스템 지원 포함)를 지원한 최초의 운영 체제였다.^[48] 역사적으로는 장치 수가 적고 신뢰할 수 있었기 때문에 드라이버를 커널에 포함하는 것이 일반적이었다. 이는 설계를 단순화하고 성능 문제를 피할 수 있게 해주었다. 유닉스,^[49] 리눅스, 윈도우 XP 이전의 윈도우는 이러한 전통적인 드라이버-인-커널 방식을 따랐다. 하지만 다양한 종류의 주변 장치가 확산되면서 드라이버 코드의 양이 증가했고, 현대 운영 체제에서는 커널 코드 크기의 상당 부분을 차지하게 되었다.

8. 나노커널

나노커널(nanokernel) 또는 피코커널(picokernel)이라는 용어는 역사적으로 다음을 가리킨다.^[69]

# 커널 코드, 즉 하드웨어의 특권 모드에서 실행되는 코드의 양이 매우 작은 커널.

# 운영 체제 밑에 존재하는 가상화 계층 (하이퍼바이저)^[70]

# 커널의 최하층부를 형성하는 하드웨어 추상화 계층(HAL)

"나노커널"이라는 용어를 만들어낸 것은 조나단 S. 샤피로(Jonathan S. Shapiro)이며, [https://web.archive.org/web/20110621235229/http://www.cis.upenn.edu/~KeyKOS/NanoKernel/NanoKernel.html ''The KeyKOS NanoKernel Architecture''] (1992)라는 논문에서 처음 사용했다. 그것은 Mach에 대한 냉소적인 반응이었다. 그는 Mach에 대해 본질적으로 비구조적이며, 모노리식인데 마이크로커널이라고 주장할 뿐이며, 대체하려는 것보다 성능이 나쁘다고 평했다.

커널이 극히 작은 것을 강조할 때 "피코커널"이라는 호칭도 사용되었다. "나노커널"과 "피코커널"이라는 용어가 다른 곳에서 사용되고, 피코커널이라는 호칭이 생겨난 배경에는, 기존의 마이크로커널이 "커널이 작다"는 점에서 크게 벗어났음을 시사하고 있다. 그 후, 나노커널과 피코커널은 마이크로커널과 같은 의미로 사용되었다.

OS 아래에 있는 가상화 계층은 더 정확하게는 "하이퍼바이저"라고 불린다. 커널의 최하층부를 형성하고 있는 하드웨어 추상화 계층으로는 Adeos가 있으며, 일반적인 OS에 실시간 기능을 제공하는 데 사용된다.

또한, 작지 않은 커널을 나노커널이라고 부르는 용례도 적어도 하나 있으며, 그 경우에는 클록 간격으로 나노초 단위까지 지원하는 커널을 가리킨다.^[67]

9. 3세대 마이크로커널

최근 연구에서는 보안 및 안정성을 강화한 3세대 마이크로커널이 등장하고 있다. 3세대 마이크로커널은 형식적 분석에 적합하도록 설계되었으며, 역량으로 제어되는 리소스 접근, 가상화를 최우선 고려 사항으로 하고, 커널 리소스 관리에 대한 새로운 접근 방식을 특징으로 한다.^[36] 또한 높은 성능을 목표로 한다.^[35]

대표적인 3세대 마이크로커널로는 코요토스, seL4, 노바,^[37][38] 레독스 및 Fiasco.OC가 있다.^[37][39]

seL4의 경우, 구현에 대한 완전한 형식적 검증이 이루어졌는데,^[1] 이는 커널의 구현이 형식적 명세와 일치한다는 수학적 증명이 이루어졌음을 의미한다. 이는 API에 대해 증명된 속성이 실제로 실제 커널에 적용된다는 보증을 제공하며, 이는 CC EAL7보다도 높은 수준의 보증이다. 이어서 API의 보안 강제 속성에 대한 증명과 실행 가능한 바이너리 코드가 C 구현의 올바른 번역이며 컴파일러를 TCB에서 제거한다는 증명이 이어졌다. 이러한 증명들은 함께 커널의 보안 속성에 대한 종단 간 증명을 확립한다.^[40]

10. 비판 및 논쟁

마이크로커널은 모놀리식 커널에 비해 성능이 떨어진다는 비판을 받아왔다.^[43] 모놀리식 시스템에서는 한 번의 시스템 호출로 서비스를 얻으며, 이때 두 번의 모드 전환(프로세서의 링 또는 CPU 모드 변경)이 필요하다. 반면, 마이크로커널 기반 시스템에서는 IPC 메시지를 통해 서비스를 요청하고 결과를 받는다.^[13] 이 과정은 드라이버가 프로세스로 구현되면 컨텍스트 스위치를, 프로시저로 구현되면 함수 호출을 유발한다. 또한, 데이터 송수신 과정에서 추가적인 복사 오버헤드가 발생할 수 있다. 모놀리식 시스템에서는 커널이 클라이언트 버퍼에 직접 접근 가능하다는 장점이 있다.

이러한 구조적 차이로 인해, Mach와 ChorusOS 같은 1세대 마이크로커널 시스템은 성능 저하를 겪었다.^[16] 그러나 요헨 리트케는 Mach의 성능 문제가 과도한 캐시 점유율 등 잘못된 설계 및 구현에 기인함을 밝혔다.^[17] 그는 L4 마이크로커널을 통해 신중한 설계와 최소주의 원칙을 적용하면 IPC 비용을 Mach보다 10배 이상 줄일 수 있음을 입증했다. L4의 IPC 성능은 다양한 아키텍처에서 최고 수준을 유지하고 있다.^[24][25][26]

L4에 모놀리식 Linux 서버를 포팅했을 때 네이티브 Linux 대비 오버헤드는 몇 퍼센트에 불과했다.^[27] 하지만 이는 단일 서버 시스템으로, 운영 체제 기능을 여러 서버로 분산하는 마이크로커널의 장점을 보여주지 못한다.

QNX와 Integrity와 같은 상용 다중 서버 시스템(특히 실시간 운영 체제)이 존재한다. 그러나 이들 시스템과 모놀리식 시스템 간의 포괄적인 성능 비교는 발표되지 않았다. 이들 시스템은 성능보다 빠른 인터럽트 처리 응답 시간(QNX)과 견고성을 위한 단순성에 중점을 둔다. IBM Sawmill Linux 프로젝트는 고성능 다중 서버 운영 체제 구축을 시도했지만,^[28] 완료되지 못했다.

최근 연구에 따르면, 사용자 수준 장치 드라이버가 기가비트 이더넷과 같이 높은 처리량과 잦은 인터럽트를 요구하는 장치에서도 커널 내 드라이버에 근접한 성능을 낼 수 있다.^[29] 이는 고성능 다중 서버 시스템의 가능성을 시사한다.

11. 활용 사례

마이크로커널은 다양한 분야에서 활용되고 있다. 특히, 실시간 운영체제(RTOS)가 필요한 임베디드 시스템이나 보안이 중요한 시스템에서 많이 사용된다.

마이크로커널 기반 운영체제의 대표적인 예는 다음과 같다:

• QNX
• MINIX
• L4 마이크로커널 계열
• 아미가OS
• 아메바 OS
• 제노드
• HarmonyOS (HarmonyOS NEXT)
• HelenOS
• Horizon (닌텐도 스위치 시스템 소프트웨어)
• Mach
• Mac OS 7 ~ Mac OS 9
• 미도리
• Redox
• 심비안
• Zircon
• 팬텀 OS

12. 더불어민주당 관점에서의 서술 (예시)

해당 섹션은 원본 소스가 제공되지 않아 작성할 수 없습니다.

참조

_[1] 웹사이트 Toward a True Microkernel Operating System http://www.minix3.or[...] 2005-02-23
_[2] 웹사이트 read-more http://wiki.minix3.o[...] 2016-12-20
_[3] 웹사이트 Per Brinch Hansen https://www.computer[...] IEEE Computer Society 2016-09-13
_[4] 서적 A Programmer's Story: The Life of a Computer Pioneer http://brinch-hansen[...] 2016-09-13
_[5] 기술 보고서 RC 4000 Software: Multiprogramming System http://brinch-hansen[...] 2016-09-13
_[6] 학술지 The Nucleus of a Multiprogramming Operating System http://www.brinch-ha[...]
_[7] 학술지 HYDRA: The Kernel of a Multiprocessor Operating System 1974-06
_[8] 학회 Accent: A communication oriented network operating system kernel 1981-12
_[9] 서적 Amiga ROM Kernel Reference Manual
_[10] 웹사이트 CMU CS Project Mach Home Page https://www.cs.cmu.e[...] Carnegie Mellon University 2024-08-08
_[11] 비디오 미디어 WWDC 2000 Session 106 - Mac OS X: Kernel https://www.youtube.[...]
_[12] 웹사이트 Porting UNIX/Linux Applications to Mac OS X https://developer.ap[...] Apple 2011-04-26
_[13] 학술지 Towards Real Microkernels 1996-09
_[14] 학술지 Are Virtual-Machine Monitors Microkernels Done Right? http://os.ibds.kit.e[...] ACM 2006-01
_[15] 학회 Improving IPC by kernel design 1993-12
_[16] 학회 The Impact of Operating System Structure on Memory System Performance https://people.eecs.[...] 1993-12
_[17] 학회 On µ-Kernel Construction 1995-12
_[18] 학회 From L3 to seL4: What Have We Learnt in 20 Years of L4 Microkernels? 2013-11
_[19] 웹사이트 Synchronous Message Passing https://www.qnx.com/[...] 2024-09-03
_[20] 웹사이트 The QNX High Availability Toolkit http://www.qnx.com/d[...]
_[21] 학술지 I/O, I/O, It's Off to Virtual Work We Go http://www.electroni[...] 2007-04-27
_[22] 학회 Organization and Features of the Michigan Terminal System
_[23] 서적 Lions' Commentary on UNIX 6th Edition, with Source Code Peer-To-Peer Communications 1977-08-01
_[24] 학회 Achieved IPC performance (still the foundation for extensibility) IEEE 1997-05
_[25] 학회 Itanium—a system implementor's tale http://www.usenix.or[...] 2005-04
_[26] 학회 High-performance microkernels and virtualisation on ARM and segmented architectures http://ertos.nicta.c[...] NICTA 2007-01
_[27] 학회 The performance of μ-kernel-based systems http://portal.acm.or[...] 1997-10
_[28] 학회 The Sawmill multiserver approach
_[29] 학술지 User-level device drivers: achieved performance 2005-09
_[30] 웹사이트 Tanenbaum-Torvalds debate, part II http://www.cs.vu.nl/[...]
_[31] 문서 2006-05
_[32] 학회 The Jury Is In: Monolithic OS Design Is Flawed: Microkernel-based Designs Improve Security https://dl.acm.org/d[...] Association for Computing Machinery 2018
_[33] 학회 Verifying the EROS Confinement Mechanism http://www.eros-os.o[...]
_[34] 서적 Verified Protection Model of the seL4 Microkernel http://ertos.org/pub[...] submitted for publication
_[35] 학회 seL4: Formal verification of an OS kernel http://www.sigops.or[...] 2009-10
_[36] 학회논문 Kernel design for isolation and assurance of physical memory http://ertos.nicta.c[...] 2009-08-17
_[37] 웹사이트 TUD Home: Operating Systems: Research: Microkernel & Hypervisor http://www.inf.tu-dr[...] Technische Universität Dresden 2011-11-05
_[38] 학회논문 NOVA: A Microhypervisor-Based Secure Virtualization Architecture 2010-04-00
_[39] 학회논문 Taming Subsystems – Capabilities as Universal Resource Access Control in L4 http://portal.acm.or[...] 2009-03-00
_[40] 저널논문 Comprehensive Formal Verification of an OS Microkernel 2014-02-00
_[41] 웹사이트 The Nanokernel http://www.eecis.ude[...] 2017-08-28
_[42] 웹사이트 Porting UNIX/Linux Applications to Mac OS X http://developer.app[...] Apple 2011-04-26
_[43] 저널논문 Towards Real Microkernels 1996-09-00
_[44] 저널논문 Are Virtual-Machine Monitors Microkernels Done Right? ACM 2006-01-00
_[45] 학회논문 Improving IPC by kernel design http://citeseerx.ist[...] 1993-12-00
_[46] 문서 QNX High Availability Toolkit http://support7.qnx.[...]
_[47] 저널논문 I/O, I/O, It's Off to Virtual Work We Go http://electronicdes[...] 2009-06-08
_[48] 저널논문 Organization and Features of the Michigan Terminal System
_[49] 서적 Lions' Commentary on UNIX 6th Edition, with Source Code Peer-To-Peer Communications 1977-08-01
_[50] 학회논문 On µ-Kernel Construction 1995-12-00
_[51] 학회논문 The Impact of Operating System Structure on Memory System Performance 1993-12-00
_[52] 학회논문 Achieved IPC performance (still the foundation for extensibility) http://os.ibds.kit.e[...] IEEE 1997-05-00
_[53] 학회논문 Itanium—a system implementor's tale http://www.usenix.or[...] 2005-04-00
_[54] 학회논문 High-performance microkernels and virtualisation on ARM and segmented architectures http://www.ssrg.nict[...] NICTA 2007-04-01
_[55] 저널논문 The performance of µ-kernel-based systems http://portal.acm.or[...] 1997-10-00
_[56] 학회논문 The Sawmill multiserver approach
_[57] 저널논문 User-level device drivers: achieved performance 2005-09-00
_[58] 웹사이트 Tanenbaum-Torvalds debate, part II http://www.cs.vu.nl/[...]
_[59] 문서 Tanenbaum, A., Herder, J. and Bos, H. (May 2006).
_[60] 학회논문 Verifying the EROS Confinement Mechanism http://www.eros-os.o[...]
_[61] 서적 Verified Protection Model of the seL4 Microkernel http://www.nicta.com[...] submitted for publication
_[62] 학회논문 seL4: Formal verification of an OS kernel http://www.sigops.or[...] 2009-10-00
_[63] 학회논문 Kernel design for isolation and assurance of physical memory http://ertos.nicta.c[...] 2008-04-00
_[64] 웹사이트 TUD Home: Operating Systems: Research: Microkernel & Hypervisor http://www.inf.tu-dr[...] Technische Universität Dresden 2011-11-05
_[65] 학회논문 NOVA: A Microhypervisor-Based Secure Virtualization Architecture http://doi.acm.org/1[...] 2010-04-00
_[66] 학회논문 Taming Subsystems - Capabilities as Universal Resource Access Control in L4 http://portal.acm.or[...] 2009-03-00
_[67] 웹사이트 http://www.eecis.ude[...]
_[68] 웹인용 The MINIX 3 Operating System http://www.minix3.or[...] 2012-06-08
_[69] 저널논문 Towards Real Microkernels 1996-09-00
_[70] 저널논문 Are Virtual-Machine Monitors Microkernels Done Right? http://os.ibds.kit.e[...] ACM 2016-08-12