마이크로커널

Microkernel
각각 단일 및 마이크로커널 기반 운영 체제의 구조

컴퓨터 과학에서 마이크로커널(흔히 μ-커널로 약칭)은 운영체제(OS) 구현에 필요한 메커니즘을 제공할 수 있는 소프트웨어의 최소 양에 가깝다.이러한 메커니즘에는 낮은 수준의 주소 공간 관리, 스레드 관리 및 프로세스 간 통신(IPC)이 포함된다.

하드웨어가 여러 링 또는 CPU 모드를 제공하는 경우 마이크로커널은 일반적으로 감독자 또는 커널 모드라고 하는 가장 특권적인 수준에서 실행되는 유일한 소프트웨어일 수 있다.장치 드라이버, 프로토콜 스택 및 파일 시스템과 같은 전통적인 운영 체제 기능은 일반적으로 마이크로커널 자체에서 제거되고 대신 사용자 공간에서 실행된다.[1]

소스 코드 크기 측면에서 마이크로커널은 종종 단일 커널보다 작다.예를 들어, MINIX 3 마이크로커널은 약 12,000줄의 코드만 가지고 있다.[2]

역사

마이크로커널은 덴마크 컴퓨터의 선구자 페르 브린치 한센과 그가 RC 4000 컴퓨터의 소프트웨어 개발 노력을 이끌었던 덴마크 컴퓨터 회사 레지센트랄렌에서 그의 재임기간 동안 그들의 뿌리를 추적한다.[3]1967년 레그네센트랄렌은 푸와비에 있는 폴란드 비료공장에 RC 4000 시제품을 설치하고 있었다.컴퓨터는 발전소의 요구에 맞춘 소규모 실시간 운영 체제를 사용했다.브린치 한센과 그의 팀은 RC 4000 시스템의 일반성과 재사용성의 부족에 대해 걱정하게 되었다.그들은 각 설치마다 다른 운영 체제가 필요할 것을 우려하여 RC 4000용 소프트웨어를 만드는 새로운 방법과 더 일반적인 방법을 조사하기 시작했다.[4]1969년, 그들의 노력은 RC 4000 멀티프로그래밍 시스템을 완성하는 결과를 낳았다.그것의 핵은 최대 23개의 권한 없는 프로세스에 대한 메시지 전달에 기반한 프로세스 간 통신을 제공했고, 이 중 한 번에 8개가 서로로부터 보호되었다.그것은 또한 병렬로 실행된 프로그램의 시간 조각 스케줄링, 다른 실행 중인 프로그램의 요청에 따른 프로그램 실행의 시작 및 제어, 주변기기로의 데이터 전송의 개시 등을 구현했다.이러한 기본적인 메커니즘 외에 프로그램 실행과 자원 배분을 위한 내장 전략이 없었다.이 전략은 상위 프로세스가 하위 프로세스를 완전히 제어하고 운영 체제 역할을 하는 실행 프로그램의 계층에 의해 구현되는 것이었다.[5][6]

브린치 한센의 작업에 이어 1970년대부터 마이크로커널이 개발됐다.[7]마이크로커널이라는 용어 자체가 처음 등장한 것은 1981년이다.[8]마이크로커널은 컴퓨터 세계의 변화와 기존의 "모노커널"을 이러한 새로운 시스템에 적응시키는 몇 가지 어려움에 대한 대응으로 의도되었다.새로운 장치 드라이버, 프로토콜 스택, 파일 시스템 및 기타 하위 수준 시스템이 항상 개발되고 있었다.이 코드는 일반적으로 단일 커널에 위치했기 때문에 작업하는 데 상당한 작업과 세심한 코드 관리가 필요했다.마이크로커널은 이러한 모든 서비스가 다른 서비스처럼 사용자 공간 프로그램으로 구현되어 단일화된 작업을 할 수 있게 된다는 생각으로 개발되었으며 다른 프로그램처럼 시작 및 중단되었다.이렇게 되면 이러한 서비스를 보다 쉽게 작업할 수 있을 뿐만 아니라 의도하지 않은 부작용에 대한 걱정 없이 정교하게 튜닝할 수 있도록 커널 코드를 분리할 수 있을 것이다.게다가, 그것은 완전히 새로운 운영 체제를 공통의 핵심에서 "구축"할 수 있게 해 OS 연구를 도울 것이다.

마이크로커널은 최초의 사용 가능한 지역 네트워크가 도입되던 1980년대에 매우 화제가 되었다.[citation needed]아미가OS Exec 커널은 1986년에 도입되어 비교적 상업적인 성공을 거둔 PC에서 사용되는 초기 사례였다.다른 측면에서는 결함으로 간주되는 메모리 보호의 부족으로 인해 이 커널은 사용자-공간 프로그램 간에 메시지를 교환하면서 데이터를 복사할 필요가 없었기 때문에 메시지 전달 성능이 매우 높았다.[9]

커널을 사용자 공간으로 분배할 수 있게 한 것과 동일한 메커니즘도 시스템이 네트워크 링크에 걸쳐 분산될 수 있도록 했다.최초의 마이크로커널, 특히 리처드 라시드가 만든 마하에는 실망스러운 성능이 입증되었지만, 본질적인 이점은 1990년대 후반에 이르러서는 주요한 연구 라인이 될 정도로 크게 나타났다.[citation needed]그러나 이 시기에 네트워킹 시스템과 관련하여 컴퓨터의 속도가 크게 증가하였고, 성능의 단점이 개발 측면에서의 장점을 압도하게 되었다.[citation needed]

기존 시스템이 더 나은 성능을 갖도록 적응하기 위한 많은 시도가 있었지만, 오버헤드는 항상 상당했고 이러한 노력의 대부분은 사용자 공간 프로그램을 커널로 다시 이동시킬 것을 요구하였다.By 2000, most large-scale Mach kernel efforts had ended, although Apple's macOS, released in 2001, still uses a hybrid kernel called XNU, which combines a heavily modified (hybrid) OSF/1's Mach kernel (OSFMK 7.3 kernel) with code from BSD UNIX,[10][11] and this kernel is also used in iOS, tvOS, and watchOS.윈도 NT는 NT 3.1로 시작하고 윈도 10으로 계속되며 하이브리드 커널 디자인을 사용한다.2012년 현재 마하 기반의 GNU Hurd도 기능하고 있으며 Arch Linux와 Debian의 시험 버전에 포함되어 있다.

마이크로커널에 대한 주요 작업은 대부분 끝났지만, 실험자들은 개발을 계속했다.[citation needed]그 후, 초기 설계의 성능 문제들 중 다수가 개념의 근본적인 제약이 아니라, 가능한 한 많은 이러한 서비스를 구현하기 위해 단일 목적 시스템을 이용하려는 설계자의 욕구 때문이었다는 것이 밝혀졌다.[citation needed]조립 코드를 포함한 문제에 대한 보다 실용적인 접근법을 사용하고 프로세서에 의존하여 소프트웨어에서 일반적으로 지원되는 개념을 시행함으로써 성능이 획기적으로 개선된 새로운 일련의 마이크로커널을 만들었다.

마이크로커널은 엑소커넬과 밀접한 관련이 있다.[12]또한 하이퍼바이저와 많은 공통점을 가지고 있지만,[13] 하이퍼바이저에는 최소화를 주장하지 않으며 가상 머신을 지원하는 데 특화된 L4 마이크로커널은 하이퍼바이저 용량에서 자주 사용된다고 한다.

소개

초기 운영 체제 커널은 컴퓨터 메모리가 제한되었기 때문에 다소 작았다.컴퓨터의 기능이 성장함에 따라 커널이 제어해야 하는 기기의 수도 증가했다.유닉스의 초기 역사를 통틀어 커널은 다양한 장치 드라이버와 파일 시스템 구현을 포함했음에도 불구하고 일반적으로 작았다.주소 공간이 16비트에서 32비트로 증가하자 커널 설계는 더 이상 하드웨어 아키텍처에 의해 제약을 받지 않게 되었고 커널은 점점 커지기 시작했다.

Unix의 BSD(Berkeley Software Distribution)는 더 큰 커널의 시대를 시작했다.BSD는 CPU, 디스크, 프린터로 구성된 기본 시스템을 운영하는 것 외에도 네트워크를 통해 기존 프로그램이 '보이지 않게' 작동할 수 있도록 하는 완전한 TCP/IP 네트워킹 시스템과 다수의 "가상" 장치를 추가했다.이러한 성장은 수년 동안 계속되었고, 결과적으로 수백만 줄의 소스 코드를 가진 커널이 되었다.이러한 성장의 결과, 낟알은 벌레가 되기 쉬우며 점점 유지하기가 어려워졌다.

마이크로커널은 이러한 커널의 성장과 그로 인한 어려움을 다루기 위한 것이었다.이론적으로 마이크로커널 설계는 사용자 공간 서비스로의 분할로 인해 코드를 보다 쉽게 관리할 수 있다.이는 또한 커널 모드에서 실행되는 코드의 양을 줄임으로써 보안과 안정성을 높일 수 있다.예를 들어, 네트워크 서비스가 버퍼 오버플로로 인해 다운되면 네트워크 서비스의 메모리만 손상되어 시스템의 나머지 부분은 여전히 작동하게 된다.

프로세스 간 통신

IPC(Process Inter-process communication, IPC)는 보통 메시지를 전송함으로써 서로 다른 프로세스가 통신할 수 있도록 하는 모든 메커니즘이다.공유기억은 엄격하게 정의된 프로세스 간 통신 메커니즘이기도 하지만, 약칭 IPC는 보통 메시지 전달만을 가리키며, 특히 마이크로커널과 관련된 것은 후자다.IPC는 IPC를 통해 호출되는 시스템의 다른 프로그램들에 의해 사용되는 서버라고 불리는 다수의 더 작은 프로그램들로부터 운영체제를 구축할 수 있도록 한다.주변 하드웨어에 대한 대부분의 또는 모든 지원은 장치 드라이버, 네트워크 프로토콜 스택, 파일 시스템, 그래픽 등을 위한 서버와 함께 이러한 방식으로 처리된다.

IPC는 동기식 또는 비동기식일 수 있다.비동기 IPC는 송신자가 메시지를 발송하고 실행을 계속하는 네트워크 통신과 유사하다.수신자는 메시지의 가용성을 확인(폴링)하거나 일부 통지 메커니즘을 통해 메시지를 경고한다.비동기 IPC는 커널이 메시지의 버퍼와 대기열을 유지하고 버퍼 오버플로를 처리할 것을 요구한다. 또한 메시지의 이중 복사(커널과 커널을 수신기로 교환하는 것)도 필요하다.동기식 IPC에서는 상대방이 IPC를 수행할 준비가 될 때까지 제1 당사자(수신자 또는 수신자)가 차단한다.버퍼링이나 복수의 복사를 필요로 하지 않지만, 암묵적인 랑데뷰는 프로그래밍을 까다롭게 만들 수 있다.대부분의 프로그래머들은 비동기 전송과 동기식 수신을 선호한다.

1세대 마이크로커널은 통상 동기식뿐 아니라 비동기식 IPC를 지원했고 IPC 성능 저하에 시달렸다.Jochen Liedtke는 IPC 메커니즘의 설계와 구현이 이러한 저조한 성능의 근본적인 이유라고 가정했다.그의 L4 마이크로커널에서 그는 IPC 비용을 엄청나게 낮추는 방법을 개척했다.[14]여기에는 수신 작업뿐만 아니라 송신도 지원하는 IPC 시스템 호출을 포함하며, 모든 IPC를 동기식으로 만들고, 가능한 많은 데이터를 레지스터에 전달한다.또한 Liedtke는 IPC 실행 중에 송신자에서 수신기로 직접 (불완전한) 컨텍스트 스위치가 수행되는 직접 프로세스 스위치의 개념을 도입했다.L4에서와 같이 메시지의 일부 또는 전체가 레지스터로 전달되는 경우, 이것은 전혀 복사하지 않고 메시지의 등록되어 있는 부분을 전송한다.또한 스케줄러 호출의 오버헤드는 피한다. 이는 서버를 호출하는 클라이언트에 의해 IPC가 원격 프로시저 호출(RPC) 유형 방식으로 사용되는 일반적인 경우에 특히 유용하다.게으른 스케줄링이라고 불리는 또 다른 최적화에서는 IPC 중에 차단되는 스레드를 준비된 대기열에 남겨두어 IPC 동안 스케줄링 대기열을 통과하지 않는다.스케줄러가 호출되면 이러한 스레드를 적절한 대기열로 이동시킨다.많은 경우에 다음 스케줄러 호출 전에 스레드가 차단되지 않게 되듯이, 이 접근법은 중요한 작업을 절약한다.그 후 QNX와 MINIX 3가 유사한 접근법을 채택했다.[citation needed]

일련의 실험에서 Chen과 Bershard는 단일 울트릭스의 명령당 메모리 사이클(MCPI)을 4.3과 결합된 마이크로커널 마하와 비교했다.사용자 공간에서 실행되는 BSD Unix 서버.그들의 결과는 마하의 성능이 더 낮은 MCPI를 설명했고 IPC만이 시스템 오버헤드의 많은 부분을 책임지지 않는다는 것을 증명했다. 이는 IPC에만 초점을 맞춘 최적화가 제한된 효과를 가질 것임을 시사했다.[15]이후 Liedtke는 Ultrix와 Mach MCPI의 차이가 용량 캐시 누락에 의해 발생한다는 관측과 마이크로커널의 캐시 작업 세트를 획기적으로 줄이면 문제가 해결될 것이라는 결론을 내려 Chen과 Bershad의 결과를 다듬었다.[16]

클라이언트-서버 시스템에서 대부분의 통신은 비동기 원시 요소를 사용하더라도 기본적으로 동기식이며, 일반적인 작업은 서버를 호출한 후 응답을 기다리는 클라이언트이기 때문이다.또한 보다 효율적인 구현에 도움이 되기 때문에, 대부분의 마이크로커널은 일반적으로 L4의 리드를 따랐고 동기식 IPC 원시만 제공했다.비동기 IPC는 도우미 스레드를 사용하여 위에서 구현될 수 있다.그러나, 경험에 따르면 동기식 IPC의 효용이 의심스러운 것으로 나타났다. 동기식 IPC는 그 결과 동기화의 복잡성을 가지고 다른 단순한 시스템에 다중 스레드 설계를 강제한다.더욱이 RPC와 같은 서버 호출은 클라이언트와 서버를 순차적으로 호출하는데, 클라이언트와 서버는 별도의 코어로 실행될 경우 이를 피해야 한다.따라서 상용 제품에 배치된 L4 버전은 비동기 통신을 더 잘 지원하기 위해 비동기 통보 메커니즘을 추가할 필요가 있다는 것을 알게 되었다.이 신호와 같은 메커니즘은 데이터를 전달하지 않으므로 커널에 의한 버퍼링이 필요하지 않다.IPC의 두 가지 형태를 갖춤으로써, 그럼에도 불구하고 그들은 최소성의 원칙을 위반했다.다른 버전의 L4는 완전히 비동기 IPC로 전환되었다.[17]

동기식 IPC는 상대방이 준비될 때까지 제1자를 차단하기 때문에 제한 없이 사용하면 쉽게 교착상태에 빠질 수 있다.게다가, 클라이언트는 요청을 전송하고 회신을 받지 않음으로써 서버에 서비스 거부 공격을 쉽게 할 수 있다.따라서 동기식 IPC는 무기한 차단을 방지할 수 있는 수단을 제공해야 한다.많은 마이크로커널이 IPC 호출에 대한 타임아웃을 제공하며, 이는 차단 시간을 제한한다.실제로 합리적인 시간 초과 값을 선택하는 것은 어렵고, 시스템은 거의 필연적으로 클라이언트를 위한 무한한 시간 초과를 사용하고 서버에 대한 시간 초과를 거의 사용하지 않는다.결과적으로, 이러한 경향은 임의의 타임아웃을 제공하지 않고, 파트너가 준비되지 않은 경우 IPC가 즉시 실패해야 한다는 것을 나타내는 플래그만 제공하는 경향이 있다.이 접근방식은 효과적으로 0과 무한대의 두 시간 제한 값 중에서 선택권을 제공한다.L4와 MINIX의 최근 버전은 이 경로를 따라갔다(L4의 이전 버전은 시간 초과 사용).QNX는 클라이언트가 메시지 송신 통화의 일부로 응답 버퍼를 지정하도록 요구함으로써 문제를 방지한다.서버가 응답할 때 커널은 클라이언트가 응답을 명시적으로 수신할 때까지 기다릴 필요 없이 데이터를 클라이언트의 버퍼에 복사한다.[18]

서버

마이크로커널 서버는 커널이 대부분의 프로그램에 대한 제한에서 벗어난 물리적 메모리의 일부와 상호작용할 수 있는 권한을 부여한다는 점을 제외하고 본질적으로 다른 어떤 것과 마찬가지로 데몬 프로그램이다.이를 통해 일부 서버, 특히 기기 드라이버가 하드웨어와 직접 상호작용할 수 있다.

범용 마이크로커널을 위한 기본 서버 집합에는 파일 시스템 서버, 장치 드라이버 서버, 네트워킹 서버, 디스플레이 서버 및 사용자 인터페이스 장치 서버가 포함된다.이 서버 세트(QNX에서 꺼낸)는 유닉스 단일 커널에서 제공하는 서비스 세트를 대략 제공한다.필요한 서버는 시스템 시작 시 시작되고 파일, 네트워크, 기기 접속 등의 서비스를 일반 애플리케이션 프로그램에 제공한다.이러한 서버가 사용자 애플리케이션의 환경에서 실행되는 상황에서 서버 개발은 커널 개발에 필요한 빌드 앤 부트 프로세스보다는 일반적인 애플리케이션 개발과 유사하다.

또한 서버를 중지하고 재시작하는 것만으로 많은 "충돌"을 수정할 수 있다.그러나, 시스템 상태의 일부는 고장난 서버로 인해 손실되므로, 이 접근방식은 고장에 대처하기 위해 응용 프로그램이 필요하다.TCP/IP 연결을 담당하는 서버를 예로 들 수 있다.이 서버가 다시 시작되면, 애플리케이션은 네트워크 시스템에서 정상적인 발생인 "잃어버린" 연결을 경험하게 될 것이다.다른 서비스의 경우, 실패는 덜 예상되며 애플리케이션 코드의 변경이 필요할 수 있다.QNX의 경우 재시작 기능이 QNX High Availability Toolkit으로 제공된다.[19]

장치 드라이버

장치 드라이버는 DMA(Direct Memory Access)를 자주 수행하므로 다양한 커널 데이터 구조를 포함한 물리적 메모리의 임의 위치에 쓸 수 있다.그러므로 그러한 운전자들은 신뢰되어야 한다.이것은 그들이 커널의 일부임에 틀림없다는 것을 의미한다는 것은 일반적인 오해다.사실, 드라이버는 본질적으로 커널의 일부가 됨으로써 더 또는 덜 신뢰할 수 있는 것은 아니다.

사용자 공간에서 장치 드라이버를 실행한다고 해서 잘못된 작동으로 인해 발생할 수 있는 손상을 줄일 수는 없지만, 실제로는 (악의가 아닌) 드라이버가 있는 상태에서 시스템 안정성에 이롭다: 드라이버 코드 자체에 의한 메모리 액세스 위반(장치와 반대되는)은 여전히 메모리 관리 하드에 의해 포착될 수 있다.제품. 게다가, 많은 장치들은 DMA가 가능하지 않고 사용자 공간에서 실행함으로써 신뢰할 수 없는 드라이버로 만들어질 수 있다.최근에 점점 더 많은 수의 컴퓨터가 IOMMU를 특징으로 하고 있는데, 이 중 다수는 장치의 물리적 메모리에 대한 접근을 제한하는 데 사용될 수 있다.[20]이것은 또한 사용자 모드 드라이버가 신뢰할 수 없게 한다.

사용자 모드 드라이버는 실제로 마이크로커널보다 앞선다.1967년 미시간 터미널 시스템(MTS)은 사용자 공간 드라이버(파일 시스템 지원 포함)를 지원했는데, 이는 이러한 기능을 갖춘 최초의 운영체제였다.[21]역사적으로, 드라이버는 덜 문제가 있었는데, 장치의 수가 적고 어쨌든 신뢰가 높았기 때문에 커널에 장치들을 넣어두면 설계가 단순화되고 잠재적인 성능 문제가 발생하지 않기 때문이다.이는 유닉스, 리눅스,[22] 윈도 NT의 전통적인 드라이버 인더커널 스타일로 이어졌다.다양한 종류의 주변기기가 확산되면서 드라이버 코드의 양이 증가했고 현대 운영체제는 코드 크기의 커널을 지배한다.

필수 구성 요소 및 최소성

마이크로커널은 위에 임의의 운영 체제 서비스를 구축하는 것을 허용해야 하므로, 몇 가지 핵심 기능을 제공해야 한다.최소한 여기에는 다음이 포함된다.

이러한 미니멀한 디자인은 브린치 한센스 핵과 IBM VM의 하이퍼바이저에 의해 개척되었다.이후 Liedtke의 최소성 원칙에 공식화되었다.

개념은 마이크로커널을 커널 밖으로 이동시키는 것, 즉 경쟁적 구현을 허용하는 것이 시스템의 필수 기능 구현을 방해하는 경우에만 허용된다.[16]

일부 프로세서 아키텍처에서 사용자 프로그램으로 구현되는 장치 드라이버가 I/O 하드웨어에 액세스하기 위한 특별한 권한을 요구하더라도 다른 모든 것은 사용자 모드 프로그램에서 수행할 수 있다.

마이크로커널 설계에 있어 마찬가지로 중요한 최소성 원리와 관련된 것은 메커니즘과 정책의 분리이며, 최소 커널 위에 임의 시스템을 구축할 수 있게 하는 것이다.커널에 내장된 모든 정책은 사용자 수준에서 덮어쓸 수 없으므로 마이크로커널의 일반성을 제한한다.[12]사용자 레벨 서버에서 구현된 정책은 서버를 교체하거나 애플리케이션이 유사한 서비스를 제공하는 경쟁 서버 사이에서 선택하도록 함으로써 변경될 수 있다.

효율성을 위해 대부분의 마이크로커널에는 최소성 원칙과 정책-메커니즘 분리 원칙을 위반하여 스케줄러를 포함하고 타이머를 관리한다.

마이크로커널 기반 시스템의 시작(부팅)에는 커널에 속하지 않는 장치 드라이버가 필요하다.일반적으로 이것은 그것들이 부팅 이미지의 커널과 함께 포장된다는 것을 의미하며, 커널은 드라이버의 위치 및 시작 방법을 정의하는 부트스트랩 프로토콜을 지원한다; 이것은 L4 마이크로커널의 전통적인 부트스트랩 절차다.일부 마이크로커널은 일부 핵심 드라이버를 커널 내부에 배치함으로써(최소성 원칙에 위배됨), LynxOS와 원본 Minix가 그 예다.어떤 것들은 심지어 부팅을 단순화하기 위해 커널에 파일 시스템을 포함하기도 한다.마이크로커널 기반 시스템은 멀티부팅 호환 부트 로더를 통해 부팅할 수 있다.그러한 시스템은 대개 정적으로 연결된 서버를 로드하여 초기 부트스트랩을 만들거나 OS 이미지를 탑재하여 부트스트래핑을 계속한다.

마이크로커널의 주요 구성요소는 IPC 시스템과 가상 메모리-관리자 설계로 사용자 모드 서버에서 페이지 오류 처리와 스와핑을 안전한 방법으로 구현할 수 있다.모든 서비스는 사용자 모드 프로그램에 의해 수행되기 때문에, 단일 커널보다 훨씬 더 프로그램들 간의 효율적인 의사소통 수단이 필수적이다.IPC 시스템의 설계는 마이크로커널을 만들거나 파괴한다.IPC 시스템이 효과적이려면 오버헤드가 낮을 뿐만 아니라 CPU 스케줄링과도 잘 상호작용해야 한다.

퍼포먼스

대부분의 메인스트림 프로세서에서, 서비스를 얻는 것은 본질적으로 단일 시스템보다 마이크로커널 기반 시스템에서 더 비싸다.[12]일체형 시스템에서는 단일 시스템 호출로 서비스를 얻는데, 여기에는 2개의 모드 스위치(프로세서의 링 또는 CPU 모드의 변경)가 필요하다.마이크로커널 기반 시스템에서 서비스는 IPC 메시지를 서버로 전송하고 그 결과를 서버에서 다른 IPC 메시지로 얻음으로써 얻어진다.이를 위해서는 운전자가 프로세스로 구현되는 경우 컨텍스트 스위치가 필요하며, 절차로 구현되는 경우 기능 호출이 필요하다.또한 실제 데이터를 서버와 백업에 전달하면 복사 오버헤드가 추가로 발생할 수 있는 반면, 단일 시스템에서 커널은 클라이언트의 버퍼에 있는 데이터에 직접 액세스할 수 있다.

따라서 마이크로커널 시스템에서는 성능 문제가 발생할 수 있다.마하, 코러소스와 같은 1세대 마이크로커널의 경험은 이를 기반으로 한 시스템의 성능이 매우 저조하다는 것을 보여주었다.[15]그러나 조센 리트케는 마하의 성능 문제가 설계와 구현, 특히 마하의 과도한 캐시 풋프린트 때문에 발생한 결과라는 것을 보여주었다.[16]Liedtke는 자신의 L4 마이크로커널을 통해 세심한 설계와 구현을 통해, 특히 최소성 원칙을 따름으로써 IPC 비용을 마하와 비교하여 한 수 이상 줄일 수 있음을 증명했다.L4의 IPC 성능은 다양한 아키텍처에서 여전히 타의 추종을 불허한다.[23][24][25]

이러한 결과는 1세대 마이크로커널 기반의 시스템 성능 저하가 L4와 같은 2세대 커널을 대표하지 않는다는 것을 보여주지만, 이는 마이크로커널 기반의 시스템을 좋은 성능으로 구축할 수 있다는 증거가 되지 못한다.L4에 포팅된 단일 리눅스 서버는 네이티브 리눅스보다 몇 퍼센트 높은 오버헤드만 보이는 것으로 나타났다.[26]그러나 그러한 단일 서버 시스템은 운영 체제 기능을 별도의 서버로 구조화함으로써 마이크로커널이 제공해야 하는 장점 중 거의 제공하지 않는다.

다수의 상용 다중 서버 시스템, 특히 실시간 시스템 QNX 및 무결성이 존재한다.이러한 다중서버 시스템에 대한 단일 시스템에 대한 성능의 종합적인 비교는 발표되지 않았다.더욱이 성능은 대신 신뢰할 수 있는 빠른 인터럽트 처리 응답 시간(QNX)과 건전성을 위해 단순성을 강조하는 상용 시스템의 최우선 관심사는 아닌 것으로 보인다.고성능 다중 서버 운영 체제를 구축하려는 시도는 IBM Sawmill Linux 프로젝트였습니다.[27]그러나 이 프로젝트는 결코 완성되지 않았다.

그동안 사용자 레벨 기기 드라이버가 기가비트 이더넷과 같은 고투과, 고인터럽트 기기에서도 인커널 드라이버의 성능에 근접할 수 있다는 것이 밝혀졌다.[28]이는 고성능 다중 서버 시스템이 가능하다는 것을 암시하는 것으로 보인다.

보안

마이크로커널의 보안 이익은 자주 논의되어 왔다.[29][30]보안의 맥락에서 마이크로커널의 최소성 원칙은, 일부에서는, 최소 특권의 원칙의 직접적인 결과로서, 모든 코드는 필요한 기능성을 제공하는 데 필요한 권한만을 가져야 한다고 주장해왔다.최소화는 시스템의 신뢰할 수 있는 컴퓨팅 기반(TCB)을 최소로 유지해야 함을 요구한다.커널(하드웨어의 특권 모드에서 실행되는 코드)이 모든 데이터에 대한 액세스를 공개하여 데이터의 무결성 또는 기밀성을 침해할 수 있으므로 커널은 항상 TCB의 일부분이다.보안 중심 설계에서는 이를 최소화하는 것이 당연하다.

결과적으로, 마이크로커널 설계는 KeyKOS, EROS 및 군사 시스템을 포함한 고도의 보안 애플리케이션을 위해 설계된 시스템에 사용되어 왔다.실제로 최고보증수준(EAL)의 공통기준(CC)은 평가대상이 "단순하다"는 명시적 요건이 있어 복잡한 시스템에 대한 진정한 신뢰도를 확립하는 것이 현실적으로 불가능하다는 것을 인정한다.다시 말하지만, "단순하다"는 용어는 오해의 소지가 있고 정의가 잘못되어 있다.적어도 국방부의 신뢰할 수 있는 컴퓨터 시스템 평가 기준은 B3/A1 수업에서 다소 더 정밀한 분석을 도입했다.

"TCB는 개념적으로 단순한 완전 보호 메커니즘을 정밀하게 정의된 의미론으로 [실행]해야 한다.중요한 시스템 엔지니어링은 TCB의 복잡성을 최소화할 뿐만 아니라 보호에 중요하지 않은 모듈을 TCB에서 제외할 것을 지시해야 한다."

— Department of Defense Trusted Computer System Evaluation Criteria

2018년 아시아 태평양 시스템 회의에서 발표된 논문은 당시 리눅스 커널에 대해 발표된 모든 중요 CVE를 조사함으로써 마이크로커널이 단일 커널보다 확실히 안전하다고 주장했다.이 연구는 문제의 40%가 공식적으로 검증된 마이크로커널에서 전혀 발생할 수 없으며 4%만이 그러한 시스템에서 완전히 완화되지 않은 상태로 남아 있을 것이라고 결론지었다.[31]

제3세대

마이크로커널에 대한 보다 최근의 작업은 커널 API의 공식적인 사양과 API의 보안 속성과 구현 정확성에 대한 공식적인 증명에 초점을 맞추고 있다.이것의 첫 번째 예는 EROS API의 단순화된 모델에 기초하여 EROS의 구속 메커니즘에 대한 수학적 증명이다.[32]좀 더 최근에(2007년) L4의 버전인 seL4의 보호 모델의 속성에 대해 기계 검사로 구성된 포괄적인 증명 집합이 수행되었다.[33]

이것이 3세대 microkernels,[34]security-oriented API로 리소스 액세스 기능에 의해 형태로 포함, 최고 관심사로 가상화, 새로운 방법 자원 management,[35]kernel는 것과 형식 분석을 위한 고등 performa의 평소 목표 외에도 적합성, 디자인 목표라 한다로 이어졌다.nce.코요토스, seL4, 노바,[36][37] 레독스, 피아스코 등이 대표적이다.OC.[36][38]

seL4의 경우, 구현에 대한 완전한 공식 검증,[34] 즉 커널의 구현이 공식 규격과 일치한다는 수학적 증거가 달성되었다.이것은 실제 커널에 대한 API 보유에 대한 속성이 실제로 증명되었다는 보증을 제공하며, CC EAL7을 능가하는 보증의 정도를 제공한다.이어서 API의 보안 강화 속성에 대한 증명과 실행 가능한 바이너리 코드가 C 구현의 올바른 번역이라는 것을 입증하는 증명서가 나와 컴파일러를 TCB에서 빼냈다.이러한 증명들을 종합하면, 커널의 보안 속성에 대한 엔드 투 엔드 증거를 확립한다.[39]

예

마이크로커널의 몇 가지 예는 다음과 같다.

나노커넬

나노커넬 또는 피코커넬이라는 용어는 역사적으로 다음을 가리켰다.

  • 커널 코드의 총 양, 즉 하드웨어의 권한 있는 모드에서 실행되는 코드의 양이 매우 적은 커널.피코커넬이라는 용어는 때때로 작은 크기를 더욱 강조하기 위해 사용되었다.나노커넬이라는 용어는 조나단 S에 의해 만들어졌다.KeyKOS NanoKernel Architecture의 샤피로.그것은 샤피로가 그것을 본질적으로 구조화되지 않고 대체하려는 시스템보다 느리고 획일적이라고 생각하는 동안 마이크로커널이라고 주장하는 마하에게 냉소적인 반응이었다.피코커넬 동전을 포함한 용어의 후속 재사용과 대응은 그 점을 크게 놓쳤음을 시사한다.나노커넬과 피코커넬 모두 마이크로커널이라는 용어로 표현되는 동일한 의미를 갖게 되었다.
  • 하이퍼바이저라고 하는 운영 체제 아래의 가상화 계층.
  • 커널의 가장 낮은 레벨의 부분을 구성하는 하드웨어 추상화 계층으로, 아데오스와 같은 일반 운영 체제에 실시간 기능성을 제공하는 데 사용되기도 한다.

또한 나노커널이라는 용어가 작은 커널이 아니라 나노초 클럭 해상도를 지원하는 것을 가리키는 경우가 적어도 하나 있다.[40]

참고 항목

참조

  1. ^ Herder, Jorrit N. (23 February 2005). "Toward a True Microkernel Operating System" (PDF). minix3.org. Retrieved 22 June 2015.
  2. ^ "read-more". Retrieved 20 December 2016.
  3. ^ "2002 Computer Pioneer Award Recipient". IEEE Computer Society. Retrieved 13 September 2016.
  4. ^ Brinch Hansen, Per (2004). A Programmer's Story: The Life of a Computer Pioneer. Retrieved 13 September 2016.
  5. ^ Brinch Hansen, Per (April 1969). RC 4000 Software: Multiprogramming System (PDF) (Technical report). Regnecentralen. Retrieved 13 September 2016.
  6. ^ Brinch Hansen, Per (1970). "The Nucleus of a Multiprogramming Operating System" (PDF). Communications of the ACM. 13 (4): 238–250. CiteSeerX 10.1.1.105.4204. doi:10.1145/362258.362278. S2CID 9414037.
  7. ^ .Wulf, William; Cohen, Ellis; Corwin, William; Jones, Anita; Levin, Roy; Pierson, C.; Pollack, Fred (June 1974). "HYDRA: The Kernel of a Multiprocessor Operating System". Communications of the ACM. 17 (6): 337–345. doi:10.1145/355616.364017. S2CID 8011765.
  8. ^ Rashid, Richard; Robertson, George (December 1981). Accent: A communication oriented network operating system kernel. SOSP '81 Proceedings of the eighth ACM symposium on Operating systems principles. Pacific Grove, California, USA. pp. 64–75. doi:10.1145/800216.806593.
  9. ^ Sassenrath, Carl (1986). Amiga ROM Kernel Reference Manual. Exec.
  10. ^ Jim Magee. WWDC 2000 Session 106 - Mac OS X: Kernel. 14 minutes in. Archived from the original on 11 December 2021.
  11. ^ "Porting UNIX/Linux Applications to Mac OS X". Apple. Retrieved 26 April 2011.
  12. ^ a b c Liedtke, Jochen (September 1996). "Towards Real Microkernels". Communications of the ACM. 39 (9): 70–77. doi:10.1145/234215.234473. S2CID 2867357.
  13. ^ Heiser, Gernot; Uhlig, Volkmar; LeVasseur, Joshua (January 2006). "Are Virtual-Machine Monitors Microkernels Done Right?". ACM SIGOPS Operating Systems Review. ACM. 40 (1): 95–99. doi:10.1145/1113361.1113363. S2CID 7414062.
  14. ^ Liedtke, Jochen (December 1993). Improving IPC by kernel design. 14th ACM Symposium on Operating System Principles. Asheville, NC, USA. pp. 175–88. CiteSeerX 10.1.1.40.1293.
  15. ^ a b Chen, J. Bradley; Bershad, Brian N. (December 1993). The Impact of Operating System Structure on Memory System Performance (PDF). SOSP '93 Proceedings of the fourteenth ACM symposium on Operating systems principles. Asheville, NC, USA. pp. 120–133. doi:10.1145/168619.168629.
  16. ^ a b c Liedtke, Jochen (December 1995). On µ-Kernel Construction. SOSP '95 Proceedings of the fifteenth ACM symposium on Operating systems principles. Copper Mountain Resort, CO, USA. pp. 237–250. doi:10.1145/224056.224075.
  17. ^ Elphinstone, Kevin; Heiser, Gernot (November 2013). From L3 to seL4: What Have We Learnt in 20 Years of L4 Microkernels?. SOSP '13 Proceedings of the Twenty-Fourth ACM Symposium on Operating Systems Principles. Farmington, PA, USA. pp. 133–150. doi:10.1145/2517349.2522720.
  18. ^ "Synchronous Message Passing". Retrieved 14 July 2019.
  19. ^ "The QNX High Availability Toolkit" (PDF). Archived from the original (PDF) on 24 August 2005.
  20. ^ Wong, William (27 April 2007). "I/O, I/O, It's Off to Virtual Work We Go". Electronic Design. Retrieved 8 June 2009.
  21. ^ Alexander, Michael T. (1971). "Organization and Features of the Michigan Terminal System". Proceedings of the November 16–18, 1971, Fall Joint Computer Conference. 40: 589–591. doi:10.1145/1478873.1478951. S2CID 14614148.
  22. ^ Lions, John (1 August 1977). Lions' Commentary on UNIX 6th Edition, with Source Code. Peer-To-Peer Communications. ISBN 978-1-57398-013-5.
  23. ^ Liedtke, Jochen; Elphinstone, Kevin; Schönberg, Sebastian; Härtig, Hermann; Heiser, Gernot; Islam, Nayeem; Jaeger, Trent (May 1997). Achieved IPC performance (still the foundation for extensibility). 6th Workshop on Hot Topics in Operating Systems. Cape Cod, MA, USA: IEEE. pp. 28–31.
  24. ^ Gray, Charles; Chapman, Matthew; Chubb, Peter; Mosberger-Tang, David; Heiser, Gernot (April 2005). Itanium—a system implementor's tale. USENIX Annual Technical Conference. Annaheim, CA, USA. pp. 264–278.
  25. ^ van Schaik, Carl; Heiser, Gernot (January 2007). High-performance microkernels and virtualisation on ARM and segmented architectures. 1st International Workshop on Microkernels for Embedded Systems. Sydney, Australia: NICTA. pp. 11–21. Archived from the original on 26 April 2007. Retrieved 1 April 2007.
  26. ^ Härtig, Hermann; Hohmuth, Michael; Liedtke, Jochen; Schönberg, Sebastian (October 1997). "The performance of µ-kernel-based systems". Proceedings of the Sixteenth ACM Symposium on Operating Systems Principles: 66–77. doi:10.1145/268998.266660. ISBN 0-89791-916-5. S2CID 1706253.
  27. ^ Gefflaut, Alain; Jaeger, Trent; Park, Yoonho; Liedtke, Jochen; Elphinstone, Kevin J.; Uhlig, Volkmar; Tidswell, Jonathon E.; Deller, Luke; et al. (2000). The Sawmill multiserver approach. 9th ACM SIGOPS European Workshop. Kolding, Denmark. pp. 109–114. CiteSeerX 10.1.1.25.8376.
  28. ^ Leslie, Ben; Chubb, Peter; FitzRoy-Dale, Nicholas; Götz, Stefan; Gray, Charles; Macpherson, Luke; Potts, Daniel; Shen, Yueting; Elphinstone, Kevin; Heiser, Gernot (September 2005). "User-level device drivers: achieved performance". Journal of Computer Science and Technology. 20 (5): 654–664. doi:10.1007/s11390-005-0654-4. S2CID 1121537.
  29. ^ Tanenbaum, Andrew S. "Tanenbaum-Torvalds debate, part II".
  30. ^ 타넨바움, A, 허더, J, 보스(2006년 5월).
  31. ^ Biggs, Simon; Lee, Damon; Heiser, Gernot (2018). "The Jury Is In: Monolithic OS Design Is Flawed: Microkernel-based Designs Improve Security". Proceedings of the 9th Asia-Pacific Workshop on Systems. Jeju Island, Republic of Korea: Association for Computing Machinery. pp. 1–7. doi:10.1145/3265723.3265733.
  32. ^ Shapiro, Jonathan S.; Weber, Samuel. Verifying the EROS Confinement Mechanism. IEEE Conference on Security and Privacy. Archived from the original on 3 March 2016.
  33. ^ Elkaduwe, Dhammika; Klein, Gerwin; Elphinstone, Kevin (2007). Verified Protection Model of the seL4 Microkernel. submitted for publication.
  34. ^ a b Klein, Gerwin; Elphinstone, Kevin; Heiser, Gernot; Andronick, June; Cock, David; Derrin, Philip; Elkaduwe, Dhammika; Engelhardt, Kai; Kolanski, Rafal; Norrish, Michael; Sewell, Thomas; Tuch, Harvey; Winwood, Simon (October 2009). seL4: Formal verification of an OS kernel (PDF). 22nd ACM Symposium on Operating System Principles. Big Sky, MT, USA.
  35. ^ Elkaduwe, Dhammika; Derrin, Philip; Elphinstone, Kevin (April 2008). Kernel design for isolation and assurance of physical memory. 1st Workshop on Isolation and Integration in Embedded Systems. Glasgow, UK. doi:10.1145/1435458. Archived from the original on 24 April 2010. Retrieved 17 August 2009.
  36. ^ a b "TUD Home: Operating Systems: Research: Microkernel & Hypervisor". Faculty of Computer Science. Technische Universität Dresden. 12 August 2010. Retrieved 5 November 2011.
  37. ^ Steinberg, Udo; Kauer, Bernhard (April 2010). NOVA: A Microhypervisor-Based Secure Virtualization Architecture. Eurosys 2010. Paris, France. pp. 209–222. doi:10.1145/1755913.1755935.
  38. ^ Lackorzynski, Adam; Warg, Alexander (March 2009). Taming Subsystems – Capabilities as Universal Resource Access Control in L4. IIES'09: Second Workshop on Isolation and Integration in Embedded Systems. Nuremberg, Germany. CiteSeerX 10.1.1.629.9845.
  39. ^ Klein, Gerwin; Andronick, June; Elphinstone, Kevin; Murray, Toby; Sewell, Thomas; Kolanski, Rafal; Heiser, Gernot (February 2014). "Comprehensive Formal Verification of an OS Microkernel". ACM Transactions on Computer Systems. 32 (1): 2:1–2:70. doi:10.1145/2560537. S2CID 4474342.
  40. ^ David L. Mills and Poul-Henning Kamp (28 November 2000). "The Nanokernel" (PDF). Retrieved 28 August 2017.

추가 읽기