8. Споріднені дослідження
Ми є не першими дослідниками, що намагаються запобігти відмови систем з вини драйверів пристроїв, що містять помилки. І ми не перші намагаємося застосувати мінімальне ядро в якості можливого рішення. Ми навіть не є першими серед тих, що реалізовував драйвери, що працюють в режимі користувача. Тим не менш, ми вважаємо, що ми першими побудували повністю POSIX-сумісну операційну систему з відмінними властивостями ізоляції збоїв поверх мінімального ядра з 3800 рядків; в цій системі кожен драйвер виконується в режимі користувача в окремому процесі, а вся ОС виконується у вигляді декількох призначених для користувача процесів. У цьому розділі ми обговоримо проекти інших дослідницьких груп, які почасти схожі на те, що робимо ми.
Ізоляція драйверів в програмному забезпеченні
Одним з найважливіших дослідницьких проектів, у якому робиться спроба побудувати надійну систему в присутності ненадійних драйверів пристроїв, є Nooks [26]. Метою Nooks є підвищення надійності існуючих операційних систем. Словами авторів, «ми націлюємо існуючі розширення на масові операційні системи, а не пропонуємо нову архітектуру розширень. Ми хочемо, щоб сьогоднішні розширення виконувалися на сьогоднішніх платформах, по можливості, без їх зміни.» Ідея полягає у зворотній сумісності з існуючими системами, але невеликі зміни дозволяються.
Підхід Nooks полягає в тому, щоб залишити драйвери пристроїв у ядрі, але укласти їх у свого роду полегшену захисну оболонку, щоб помилки драйвера не могли поширюватися на інші частини операційної системи. Nooks працює шляхом вставки прозорого рівня підвищення надійності між обертається драйверів пристрою й, що залишився частиною операційної системи. Весь трафік управління і даних між драйвером і залишилася частиною ядра перевіряється рівнем підвищення надійності. При запуску драйвера рівень підвищення надійності модифікує таблицю сторінок ядра таким чином, щоб заборонити доступ по запису до сторінок, які не є частиною драйвера, запобігаючи, тим самим, їхню безпосередню модифікацію. Для підтримки законного доступу по запису в структури даних ядра Nooks копіює необхідні дані в драйвер, а після модифікації переписує їх назад.
Наша мета повністю відрізняється від мети Nooks. Ми не намагаємося зробити більш надійними успадковані системи. Будучи дослідниками, ми задаємо питання: як слід розробляти майбутні операційні системи, щоб із самого початку запобігти виникненню цієї проблеми? Ми вважаємо, що правильна розробка майбутніх систем полягає в побудові мультисерверного операційної системи та виконання ненадійного коду в незалежних процесах в режимі користувача, що зробить цей код набагато менш шкідливим (як обговорювалося в розд. 3).
Незважаючи на різні цілі, є й технічні аспекти, у відношення яких системи можна порівнювати. Розглянемо лише кілька прикладів. Nooks не може впоратися зі складними помилками, такими як ненавмисне зміна в драйвері таблиці сторінок; в нашій системі у драйверів відсутній доступ до таблиці сторінок. Nooks не може впоратися з нескінченними циклами; ми можемо, оскільки, коли драйвер не відповідає правильним чином серверу реінкарнації, він примусово завершується і перезапускається. Хоча на практиці Nooks може в більшості випадків впоратися з неприпустимими записами в структури даних ядра, в нашій розробці такі записи не допускаються структурно. Nooks не може впоратися з драйвером принтера, який випадково намагається зробити запис в порти введення-виведення, керуючі диском; ми відловлюємо 100% таких спроб. Заслуговує на увагу й розмір коду. Nooks включає 22,000 рядків коду, майже в шість разів більше розміру всього нашого ядра і більше мінімальної конфігурації всієї нашої операційної системи. Важко відійти від цієї аксіоми: у більшому за розміром коді міститься більше помилок. Тому статистично Nooks, ймовірно, міститься в п'ять разів більше помилок, ніж у всьому нашому ядрі.
Ізоляція драйверів з використанням віртуальних машин
В іншому проекті з інкапсуляції драйверів це робиться з використанням поняття віртуальної машини для їх ізоляції від інших частин системи [19, 18]. Коли драйвер викликається, він запускається на другий віртуальній машині, не в тій, в якій працює основна система, так що його збій не псує основну систему. Подібно Nooks, цей підхід повністю фокусується на виконанні успадкованих драйверів для успадкованих операційних систем. Автори не стверджують, що для нових розробок хорошим підходом є включення ненадійного коду в ядро з подальшою захистом кожного драйвера шляхом його виконання на окремій віртуальній машині.
Хоча цей підхід дозволяє досягти намічених цілей, з ним пов'язані деякі проблеми. По-перше, є питання, пов'язані з тим, наскільки можуть довіряти один одному основна система та віртуальна машина, на якій виконується драйвер. По-друге, запуск драйвера на віртуальній машині породжує проблеми з тимчасовими співвідношеннями і блокуваннями, оскільки всі віртуальні машини працюють у режимі поділу часу, і ядерний драйвер, що розроблявся в розрахунку на виконання без переривань, може бути непередбачуваним чином квантованих в часі з непередбачуваними наслідками. По-третє, може знадобитися спільне використання кількома віртуальними машинами деяких ресурсів, таких як конфігураційне простір шини PCI. По-четверте, механізм віртуальної машини споживає додаткові ресурси, хоча відповідні витрати сумірні з витратами нашої схеми: від 3% до 8%. Хоча для цих проблем пропонуються рішення, підхід у кращому випадку є громіздким і в основному підходить для захисту успадкованих драйверів в успадкованих операційних системах, а не для використання в нових розробках, яким присвячено наше дослідження.
Засоби безпеки, засновані на мовах
У попередній роботі один з авторів також торкався проблему безпечного виконання зовнішнього коду всередині ядра. У проекті Open Kernel Environment (OKE) забезпечується безпечна, що контролює ресурси середовище, що дозволяє завантажити в ядро операційної системи Linux повністю оптимізований власний код [4]. Код компілюється з використанням спеціального компілятора Cyclone, який додає до об'єктному коду інструментарій у відповідності з політикою, яка визначається привілеями користувача. Cyclone, подібно Java, є мовою з типовою безпекою, в якому більша частина помилок, пов'язаних з покажчиками, запобігається мовними засобами. Явне довірче управління (trust management) і контроль авторизації забезпечують адміністраторам можливість здійснювати суворий контроль над наданням зовнішнім модулям привілеїв, і цей контроль автоматично приводиться у виконання в коді цих модулів. Крім забезпечення авторизації, компілятор грає центральну роль в перевірці того, що код відповідає встановленої політиці. Для цього використовуються як статичні перевірки, так і динамічний інструментарій.
OKE дозволяє зовнішнім модулям інтенсивно взаємодіяти з іншими частинами ядра, наприклад, шляхом спільного використання пам'яті ядра. Робоча середовище забезпечує ключові засоби безпеки. Зокрема, для даних завжди проводиться прибирання сміття, і не може відбутися звернення за вказівником до вільної пам'яті. Більш того, OKE може забезпечувати контроль над усіма ресурсами зовнішніх модулів ядра: час ЦП, купа, стек, точки входу і т.д.
Середа OKE розроблялася в розрахунку на написання драйверів і розширень ядра. Проте, оскільки для забезпечення безпечного програмування в ядрі Linux потрібні процедури суворого контролю доступу і складні засоби, середу досить важко використовувати. Як відзначають автори, основна причина полягає в тому, що організація Linux просто не призначена для забезпечення можливості безпечних розширень.
Віртуальні машини і екзоядра
Класичні віртуальні машини [24] представляють собою потужний засіб для одночасного виконання кількох операційних систем. Екзоядра [10] схожі на віртуальні машини, але в них ресурси швидше розділяються, а не реплікуються, що призводить до більшої ефективності. Проте жоден з цих підходів не вирішує проблему, поставлену в розд. 1.3: як запобігти відмови операційних систем з вини драйверів пристроїв, що містять помилки?
Драйвери, що виконуються в режимі користувача в монолітному ядрі
Раннім проектом, в якому застосовувалися драйвери, що виконуються в режимі користувача, був Mach 3.0 [11]. Система складалася з мікроядра Mach, поверх якого запускалася ОС Berkeley UNIX у вигляді користувацького процесу, і драйвери пристроїв також виконувалися в призначених для користувача процесах. На жаль, у разі фатального збою драйвера Berkeley UNIX доводилося перезапускати, так що від ізоляції драйверів було мало користі. Планувалася мультисерверного система, яка повинна була виконуватися над Mach, але вона так і не була повністю реалізована.
В аналогічному проекті в університеті New South Wales реалізовувалися драйвери Linux для жорсткого диска і гігабайтної апаратури Ethernet, що виконуються в режимі користувача [8]. Для блоків розміром менше 32 Кб продуктивність ядерного драйвера була значно вище, але на блоках більшого розміру вирівнювався. Під час тестування Ethernet виявилося так багато аномалій, ймовірно, пов'язаних з управлінням буферами, але не можна було зробити які-небудь висновки.
Розробки мінімальних ядер
Хоча витяг драйверів з ядра є великим кроком вперед, ще краще витягти з ядра операційну систему. Саме тут починають застосовуватися мінімальні ядра з надзвичайних скороченням числа реалізованих у них абстракцій. Ймовірно, першим мінімальним ядром була система RC4000 Брінка Хансена (Brinch Hansen), що датується початком 1970-х рр. [13]. З середини 1980-х рр. був написаний ряд мінімальних ядер, включаючи Amoeba [21], Chorus [5], Mach [1] і V [6]. Проте ні в одному з них не застосовувалося безпечне програмне забезпечення: у всіх було не ізольовані драйвери всередині ядра.
QNX є комерційною UNIX-подібної системою реального часу з закритими кодами [17]. Хоча у неї є мінімальне ядро, зване Neutrino, з приводу системи опубліковано мало статей, і точні деталі нам невідомі. Проте на основі останніх проспектів ми робимо висновок, що Neutrino є гібридним ядром, оскільки менеджер процесів працює в адресному просторі ядра.
На початку 1990 рр. покійний Йохан Лідтке (Jochen Liedtke) написав мінімальне ядро L4 мовою асемблера для архітектури x86. Швидко стало зрозуміло, що воно не є стерпним, і його важко підтримувати, і тому він переписав ядро на мові C [20]. Після цього воно продовжувало розвиватися. В даний час є дві основні гілки: L4/Fiasco, підтримуване в технічному університеті Дрездена, і L4Ka: Pistachio, підтримуване в університеті Карлсруе та університеті New South Wales. Вони написані на C + +.
Ключовими ідеями в L4 є адресні простору, нитки і IPC між нитками в різних адресних просторах. Менеджер ресурсів, що виконується в режимі користувача та запускається при завантаженні системи, управляє системними ресурсами і розподіляє їх між користувацькими процесами. L4 – це одне з небагатьох дійсно мінімальних ядер з драйверами пристроїв, що працюють у режимі користувача. Проте відсутня реалізація, в якій кожен драйвер виконувався б в окремому адресному просторі, і API L4 зовсім відрізняється від нашого API, тому ми не можемо запустити на ньому будь-які тести.
Однак виявилося неважко запустити скрипт підрахунку числа рядків над поточною версією ядра L4Ka: Pistachio. Результати показані на рис. 10, і їх можна порівняти з даними на рядку «Kernal». Розмір початкового коду майже у два рази перевищує розмір нашого ядра, а бінарний код у шість разів більше, проте функціональні можливості L4Ka: Pistachio є зовсім іншими, так що важко сказати що-небудь ще, крім того, що це ядро значно більше за розміром.
Односерверні операційні системи
Одним зі способів використання мінімальних ядер є забезпечення платформи, поверх якої, як єдиний сервер, запускається вся операційна система, можливо, в режимі користувача. Для отримання системних сервісів для користувача програми запитують їх у процесу операційної системи. Властивості такої архітектури аналогічні властивостям монолітних систем, що обговорювалося в розд. 2.1. Помилка в драйвері як і раніше може зламати всю операційну систему, а в результаті і прикладні програми. Тому, з точки зору ізоляції збоїв, виконання всієї операційної системи в одному користувача процесі нітрохи не краще її виконання в режимі ядра. Єдиним реальним перевагою є те, що перезавантаження після фатального збою сервера операційної системи, виконується в режимі користувача, і всіх додатків відбувається швидше, ніж перезавантаження комп'ютера.
Одним із прикладів цієї технології є ОС Berkeley UNIX поверх Mach (перейменована в Darwin компанією Apple), яка є основою системи Apple Mac OS X [28]. Однак у цій системі UNIX виконується в ядрі, що робить його просто інакше структурованим монолітним ядром. Другий приклад – ОС MkLinux, в якій Linux виконується в єдиному користувача процесі поверх Mach. Третій приклад – L4-Linux, в якій повний варіант Linux виконується поверх L4 [15]. В останній з перерахованих систем користувальницькі процеси отримують сервіси операційної системи шляхом виклику віддалених процедур у сервері Linux з використанням механізму IPC L4. Вимірювання показують падіння продуктивності в порівнянні із звичайною ОС Linux на 5–10%, що дуже близько до нашими спостереженнями. Однак єдина рядок з помилковим кодом в драйвері Linux може призвести до збою фатального всієї операційної системи, так що єдиним перевагою цієї архітектури з точки зору надійності є більш швидке завантаження.
Мультисерверного операційні системи
Більш складний підхід полягає в розщепленні операційної системи на частини і виконання кожної частини у власній області захисту. Одним з таких проектів був SawMill Linux [12]. Проте в 2001 р. проект був несподівано зупинений після того, як багато хто з його основних учасників пішли з IBM.
Іншим мультисерверного проектом є DROPS, в якому ОС також будується поверх мінімального ядра L4/Fiasco [14]. Цей проект орієнтована на мультимедійні додатки. Однак більшість драйверів пристроїв виконується у складі великого серверного процесу L4-Linux, і тільки мультимедійні підсистеми виконуються окремо. Після деякої настройки програш в продуктивності знизився до 2–4%.
Ще однією мультисерверного операційною системою з драйверами, що виконуються в режимі користувача, є Nemesis [23]. У цій системі є єдиний адресний простір, розділяється всіма процесами, але використовується апаратна захист між процесами. Подібно DROPS ця система була орієнтована на мультимедійні додатки, але не була POSIX-сумісною і навіть UNIX-подібної.
Висновок
Основне досягнення роботи, описаної в цій статті, полягає в тому, що ми побудували POSIX-сумісну операційну систему, засновану на мінімальному ядрі, вихідні тексти якого складають менше 3800 рядків. Тільки цей код виконується в режимі ядра. Наскільки нам відомо, наше мінімальне ядро є найменшим серед усіх існуючих ядер, які підтримують повністю POSIX-сумісну мультисерверного операційну систему, яка функціонує у режимі користувача. Унікальність нашої системи полягає також у тому, що в ній кожен драйвер пристрою виконується в окремому користувача процесі, і є можливість реінкарнації бездіяльних або невірно функціонуючих драйверів на льоту, без перезавантаження операційної системи. Ми не стверджуємо, що можемо відловити будь-яку помилку, але ми істотно підвищили надійність операційної системи шляхом структурного усунення багатьох різних класів помилок.
Для досягнення максимальної надійності у своїй розробці ми керувалися принципами простоти, модульності, найменшою авторизації і відмовостійкості. У розуміється і мінімальному ядрі міститься менша кількість помилок, і воно в меншій мірі піддається фатальним збоїв. Наприклад, у нашому коді ядра неможливі переповнення буферів, оскільки всі структури даних у ньому оголошуються статично, а не з використанням динамічного розподілу пам'яті. Крім того, шляхом переміщення більшої частини коду (і більшої частини помилок) у непривілейованих користувальницькі процеси і обмеження можливостей кожного з них ми домоглися належної ізоляції збоїв і обмежили масштаб відповідного потенційного збитку. Більш того, більшість серверів і всі драйвери в операційній системі піддаються моніторингу і автоматично відновлюються при виявленні проблеми. За це скорочення числа фатальних збоїв операційної системи ми платимо зниженням продуктивності на 5–10%. Ми вважаємо цю ціну цілком обгрунтованою.
Звичайно, драйвери, файлові системи та інші компоненти не стають в нашій розробці магічним чином безпомилковим. Однак за наявності стабільного мінімального ядра сценарій найгіршого випадку змінюється від потреби в перезавантаженні комп'ютера до потреби в перезапуску операційної системи в режимі користувача. Принаймні, це відновлення відбувається набагато швидше. У кращому випадку, якщо, скажімо, в драйвері принтера виникає аварійний відмова з причини записи по невірному вказівником, сервер реінкарнації автоматично запускає свіжу копію цього драйвера. Потрібно заново виконати поточне завдання на друк, але все це ніяк не вплине на інші програми, які виконувалися до моменту фатального збою драйвера. Ситуація з блоковими пристроями справи ще краще. Якщо виявляється збій дискового драйвера, то система може зробити повне відновлення шляхом прозорої заміни драйвера і перезапису блоків з буферного кешу файлової системи.
На завершення статті зазначимо, що ми показали, як можна підвищити надійність операційної системи з використанням елегантного, полегшеного підходу. Наша система в цей час є стійкою до більшості видів невірної роботи, що викликається помилками. Проте є нові проблеми, пов'язані із зловмисними серверами і драйверами. Ми продовжуємо дослідницьку роботу в цій області.
0 комментариев