Каковы потенциальные подводные камни при наличии минимального ядра, которое запускает управляемый код?
14
Предположим, я хочу построить операционную систему на основе очень маленького собственного нижнего ядра, которое действует как интерпретатор / среда выполнения управляемого кода, и большего верхнего ядра, скомпилированного с неродным машинным языком (байт-код 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 ++.
Этот ответ довольно слабый. Каковы «относительно простые задачи», которые вы не можете сделать без указателей (исключая крошечный фундамент)? Какие детали нуждаются в сборке? Какой контроль вам не хватает? На чем вы основываете свое заявление о накладных расходах? Почему у вас не может быть структур на управляемом языке?
Жиль "ТАК - перестань быть злым"
1. Нет никакой причины, по которой управляемый язык не предлагал бы возможность доступа к VGA-памяти, это только отображение / отображение, которое должно быть предоставлено как примитив (примитив управления памятью). 2. Некоторое переключение задач (например, сохранение регистров) обычно должно выполняться как ассемблерный код, но он очень локализован, это не аргумент против наличия 99% ОС на управляемом языке. Управление MMU является примитивом управления памятью. 4. C тоже нужно настроить (настроить стек и кучу); управляемым языкам нужно немного больше настройки, но качественной разницы нет.
Жиль "ТАК - перестань быть злым"
@ Жиль, вопрос в том, каковы проблемы развития для использования управляемого языка. Это проблемы развития, но вы все еще можете успешно преодолеть такие проблемы ...
Проблема заключается в том, что ошибки, которые могут вызвать дыру в безопасности, сильно отличаются от привычных для исследователей безопасности. В традиционном микроядре все драйверы и другие части ядра изолированы друг от друга, выполняя их в разных адресных пространствах. В микроядре, где изоляция реализована с помощью управляемого кода с проверкой типов, вы избегаете огромных накладных расходов при переключении адресных пространств каждый раз, когда вам необходимо использовать вспомогательную услугу, но компромисс заключается в том, что теперь оценка механизма изоляции более сложна.
Любая конкретная часть ядра (скажем, драйвер устройства), написанная на управляемом языке, безопасна тогда и только тогда, когда средство проверки типов говорит, что драйвер безопасен и средство проверки типов не содержит ошибок. Таким образом, средство проверки типов является частью ядра ядра. На практике кажется, что шашки типа значительно больше и сложнее, чем традиционные ядра микроядра. Это означает, что поверхность атаки потенциально больше.
Я не знаю, являются ли традиционные методы изоляции микроядра или методы изоляции на основе управляемого кода более или менее надежными. Здесь есть проблема с самозагрузкой: пока широко не используются методы изоляции управляемого кода, мы не будем знать, насколько часто они небезопасны. Но не зная, насколько они небезопасны, их сложно развернуть в ситуациях, критичных для безопасности.
Я нахожу эти аргументы очень странными. (Конечно, я могу быть предвзятым из-за своего опыта формальных методов, но это не единственное основание для моего мнения.) Проверка типов не так сложна, по сравнению с микроядром и MMU. Например, микроядро Coq составляет около 14 кОл OCaml - больше, чем микроядро, но не на столько, а написано на языке, который менее подвержен ошибкам, чем большинство ядер (без C или ассемблера). Типовые шашки не подвержены условиям гонки, которые представляют собой особенно тонкий класс ошибок.
Жиль "ТАК - перестать быть злым"
Управляемый код дает лучшую возможность обрабатывать определенный класс ошибок; например, анализ потока информации может доказать отсутствие побочных каналов (вероятно, это займет много работы, и я не знаю, в какой степени это было сделано, но в принципе это выполнимо), тогда как аппаратная изоляция позволяет только тестировать боковые каналы, о которых вы подумали.
Жиль "ТАК ... перестать быть злым"
С практической точки зрения, несколько виртуальных машин, обеспечивающих изоляцию, были сертифицированы в EAL5 и выше. Вот два примера, которые вы вполне можете иметь в своем кошельке, если вы европейцы, потому что они используются в смарт-картах, таких как кредитные карты: MULTOS , открытая платформа Java Card . В сообществе по оценке безопасности я слышал много сомнений в том, что изоляция MMU может выходить за пределы EAL2.
Я слышал, как утверждал ( исследователь, работающий над конкурирующей техникой микроядра ), что очень мало известно о том, как оценивать безопасность систем, которые расширяются с помощью управляемого кода.
Проблема заключается в том, что ошибки, которые могут вызвать дыру в безопасности, сильно отличаются от привычных для исследователей безопасности. В традиционном микроядре все драйверы и другие части ядра изолированы друг от друга, выполняя их в разных адресных пространствах. В микроядре, где изоляция реализована с помощью управляемого кода с проверкой типов, вы избегаете огромных накладных расходов при переключении адресных пространств каждый раз, когда вам необходимо использовать вспомогательную услугу, но компромисс заключается в том, что теперь оценка механизма изоляции более сложна.
Любая конкретная часть ядра (скажем, драйвер устройства), написанная на управляемом языке, безопасна тогда и только тогда, когда средство проверки типов говорит, что драйвер безопасен и средство проверки типов не содержит ошибок. Таким образом, средство проверки типов является частью ядра ядра. На практике кажется, что шашки типа значительно больше и сложнее, чем традиционные ядра микроядра. Это означает, что поверхность атаки потенциально больше.
Я не знаю, являются ли традиционные методы изоляции микроядра или методы изоляции на основе управляемого кода более или менее надежными. Здесь есть проблема с самозагрузкой: пока широко не используются методы изоляции управляемого кода, мы не будем знать, насколько часто они небезопасны. Но не зная, насколько они небезопасны, их сложно развернуть в ситуациях, критичных для безопасности.
источник