Предположим, я хочу построить операционную систему на основе очень маленького собственного нижнего ядра, которое действует как интерпретатор / среда выполнения управляемого кода, и большего верхнего ядра, скомпилированного с неродным машинным языком (байт-код Java, CIL и т. Д.). Примерами подобных операционных систем могут быть Singularity и Cosmos .
Какие подводные камни и проблемы разработки существуют при создании ОС с такой инфраструктурой в отличие от чисто нативного решения?
Ответы:
В зависимости от языка, может быть много проблем развития:
Указатели: если в языке нет указателей, будет довольно сложно выполнить относительно простые задачи. Например, вы можете использовать указатели для записи в память VGA для печати на экран. Однако в управляемом языке вам понадобится какой-то «плагин» (из C / C ++), чтобы сделать то же самое.
Сборка: ОС всегда нуждается в некоторой сборке. Такие языки, как C #, Java и т. Д., Не так хорошо работают с ним, в отличие от C / C ++. В C или C ++ также может быть встроенная сборка, которая очень, очень полезна для многих задач. Существует МНОГИЕ случаи, когда это необходимо (примеры в x86): загрузка GDT, загрузка IDT, включение подкачки, настройка IRQ и т. Д.
Контроль: если вы используете что-то вроде Космоса, у вас нет полного контроля. Космос - это микроядро и, по сути, «самозагрузка» вашего «ядра». Вы можете реализовать что-то вроде Космоса с нуля, если вы действительно этого хотите, но это может занять очень много времени.
Накладные расходы: с управляемыми языками существует много накладных расходов по сравнению с C или даже C ++. Такие вещи, как Cosmos, должны реализовать много вещей, прежде чем даже ядро мира C # hello сможет быть запущено. В C вы готовы к работе, никаких реальных настроек не требуется. В C ++ есть только несколько вещей, которые необходимо реализовать, чтобы использовать некоторые функции C ++.
Структуры: в C / C ++ есть структуры, которых нет во многих управляемых языках, и поэтому вам необходимо реализовать какой-то способ иметь что-то вроде структуры. Например, если вы хотите загрузить IDT (таблицу дескрипторов прерываний), в C / C ++ вы можете создать структуру (с упакованным атрибутом) и загрузить ее с помощью инструкции x86 ASM lidt . На управляемом языке это сделать гораздо сложнее ...
Управляемые языки, с точки зрения синтаксиса, проще, однако, для многих вещей, связанных с ОС, зачастую не очень хорошо подходят. Это не значит, что их нельзя использовать, однако часто рекомендуется что-то вроде C / C ++.
Я слышал, как утверждал ( исследователь, работающий над конкурирующей техникой микроядра ), что очень мало известно о том, как оценивать безопасность систем, которые расширяются с помощью управляемого кода.
Проблема заключается в том, что ошибки, которые могут вызвать дыру в безопасности, сильно отличаются от привычных для исследователей безопасности. В традиционном микроядре все драйверы и другие части ядра изолированы друг от друга, выполняя их в разных адресных пространствах. В микроядре, где изоляция реализована с помощью управляемого кода с проверкой типов, вы избегаете огромных накладных расходов при переключении адресных пространств каждый раз, когда вам необходимо использовать вспомогательную услугу, но компромисс заключается в том, что теперь оценка механизма изоляции более сложна.
Любая конкретная часть ядра (скажем, драйвер устройства), написанная на управляемом языке, безопасна тогда и только тогда, когда средство проверки типов говорит, что драйвер безопасен и средство проверки типов не содержит ошибок. Таким образом, средство проверки типов является частью ядра ядра. На практике кажется, что шашки типа значительно больше и сложнее, чем традиционные ядра микроядра. Это означает, что поверхность атаки потенциально больше.
Я не знаю, являются ли традиционные методы изоляции микроядра или методы изоляции на основе управляемого кода более или менее надежными. Здесь есть проблема с самозагрузкой: пока широко не используются методы изоляции управляемого кода, мы не будем знать, насколько часто они небезопасны. Но не зная, насколько они небезопасны, их сложно развернуть в ситуациях, критичных для безопасности.