관리되는 코드를 실행하는 최소한의 커널을 갖는 잠재적 인 함정은 무엇입니까?

관리 코드 인터프리터 / 런타임으로 작동하는 매우 작은 기본 하위 커널과 비원시 기계 언어 (Java 바이트 코드, CIL 등)로 컴파일 된 더 큰 상위 커널을 기반으로 운영 체제를 구축하려고한다고 가정합니다. 유사한 운영 체제의 예로는 Singularity 및 Cosmos가 있습니다.

순수 네이티브 솔루션과 달리 이러한 종류의 인프라로 OS를 작성하는 데 어떤 함정과 개발 과제가 있습니까?

언어에 따라 많은 개발 과제가있을 수 있습니다.

1. 포인터 : 언어에 포인터가 없으면 비교적 쉬운 작업을 수행하는 것이 어려울 것입니다. 예를 들어, 포인터를 사용하여 화면에 인쇄하기 위해 VGA 메모리에 쓸 수 있습니다. 그러나 관리되는 언어에서는 동일한 작업을 수행하려면 C / C ++의 "플러그"가 필요합니다.

2. 어셈블리 : OS에는 항상 일부 어셈블리가 필요합니다. C #, Java 등과 같은 언어는 C / C ++와 달리 잘 작동하지 않습니다. C 또는 C ++에서는 많은 작업에 매우 유용한 인라인 어셈블리를 가질 수도 있습니다. 이것이 필요한 많은 경우가 있습니다 (x86의 예) : GDT로드, IDT로드, 페이징 활성화, IRQ 설정 등.

3. 제어 : Cosmos와 같은 것을 사용하는 경우 전체 제어 권한이 없습니다. Cosmos는 마이크로 커널이며 본질적으로 "커널"을 "부트 스트랩"합니다. 그러나 시간이 오래 걸리는 코스모스와 같은 것을 처음부터 구현할 수 있습니다.

4. 오버 헤드 : 관리되는 언어의 경우 C 또는 C ++에 비해 많은 오버 헤드가 있습니다. Cosmos와 같은 것은 C # hello world 커널을 실행하기 전에 많은 것을 구현해야합니다. C에서는 실제 설정이 필요하지 않습니다. C ++에는 C ++ 기능 중 일부를 사용하기 위해 구현해야 할 것이 몇 가지 있습니다.

5. 구조 : C / C ++에는 많은 관리되는 언어에없는 구조체가 있으므로 구조체와 같은 방법을 구현해야합니다. 예를 들어, C / C ++에서 IDT (인터럽트 디스크립터 테이블)를로드하려는 경우 압축 된 속성으로 구조체를 작성하고 x86 ASM 명령어 lidt를 사용하여로드 할 수 있습니다. 관리되는 언어에서는 수행하기가 훨씬 어렵습니다 ...

관리되는 언어는 구문별로 쉽지만 많은 OS 관련 사항이 적합하지 않은 경우가 많습니다. 그렇다고해서 사용할 수는 없지만 C / C ++와 같은 것이 권장되는 경우가 많습니다.

( 경쟁하는 마이크로 커널 기술을 연구하는 연구원에 의해 ) 관리 코드를 통해 확장 가능한 시스템의 보안을 평가하는 방법에 대해서는 알려진 바가 거의 없다고 들었습니다 .

문제는 보안 허점을 유발할 수있는 버그 종류가 보안 연구원과는 매우 다르다는 것입니다. 전통적인 마이크로 커널에서는 커널의 모든 드라이버와 다른 서브 파트가 서로 다른 주소 공간에서 실행되어 서로 분리되어 있습니다. 유형 검사 관리 코드를 통해 격리가 구현되는 마이크로 커널에서는 하위 서비스를 사용해야 할 때마다 주소 공간을 전환 할 때 발생하는 엄청난 오버 헤드를 피할 수 있지만 이제 격리 메커니즘을 평가하는 것이 더 어렵다는 단점이 있습니다.

관리 언어로 작성된 커널의 특정 부분 (예 : 장치 드라이버)은 유형 검사기가 드라이버가 안전 하고 유형 검사기에 버그가없는 경우에만 안전합니다 . 따라서 유형 검사기는 커널 코어의 일부입니다. 실제로 타입 체커는 기존의 마이크로 커널 코어보다 상당히 크고 복잡합니다. 이는 공격 표면 이 잠재적으로 더 크다는 것을 의미합니다 .

기존의 마이크로 커널 격리 기술 또는 관리 코드 기반 격리 기술이 실제로 어느 정도 신뢰할 수 있는지 모르겠습니다. 여기에는 부트 스트랩 문제가 있습니다. 관리 코드 격리 기술이 널리 사용될 때까지 얼마나 안전하지 않은지 알 수 없습니다. 그러나 얼마나 안전하지 않은지 알지 못하면 보안이 중요한 상황에 배치하기가 어렵습니다.