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