Другий тест містив цикл, у якому компілювати тести відповідності стандарту POSIX. Набір з 42 тестових програм компілюватися за 1,577 секунди, або приблизно за 37 мсек на файл тесту. Тести з третього по сьомий складалися в сортуванні до 64-мегабайтной файлу та застосування до нього sed, grep, prep і uuencode відповідно. У цих тестах у різних обсягах змішувалися обчислення і обміни з диском. Кожен тест пропускався лише по одному разу, так що кеш файлової системи практично не використовувався, кожен блок брався з диска. Середнє падіння продуктивності склало в цих випадках 6%. Якщо взяти середнє значення для останнього стовпця показників 1922 тестів, відображених на рис. 6–8, ми отримаємо 1.08. Іншими словами, версія з драйверами, що виконуються в режимі користувача, виявилася приблизно на 8% повільніше версії з ядерними драйверами для операцій, які залучають обміни з дисками.
Мережева продуктивність
Ми тестували також і мережеву продуктивність системи з драйверами, що виконуються в режимі користувача. Тестування проводилося з використанням карти Intel Pro/100, оскільки у нас не було драйвера для карти Intel Pro/1000. Ми змогли управляти Ethernet на повній швидкості. Крім того, ми запускали тести поворотної петлі з відправником та одержувачем, що знаходяться на одній машині, і спостерігали пропускну здатність в 1.7 Гб / сек. Оскільки це еквівалентно використанню мережевого з'єднання для посилки на швидкості 1.7 Гб / сек і одночасного прийому на тій же швидкості, ми впевнені, що управління гігабітної апаратурою Ethernet з єдиним односпрямованим потоком на швидкості в 1 Гб / с не повинна створити проблему при використанні драйвера, що виконується в режимі користувача.
Розмір коду
Швидкість – це не єдиний показник, який представляє інтерес; дуже важливим є і кількість помилок. На жаль, ми не можемо безпосередньо перерахувати всі помилки, але розумним замінником числа помилок, ймовірно, є число рядків коду. Нагадаємо: чим більше код, тим більше помилок.
Підрахувати кількість рядків коду не так просто, як може здатися на перший погляд. По-перше, порожні рядки і коментарі не додають в код складності, і тому ми їх не враховуємо. По-друге, # define й інші визначення у файлах заголовків також не додають у код складності, і тому файли заголовків теж не враховуються. Підрахунок числа рядків виконувався з використанням Perl-скрипта sclc.pl, доступного в Internet. Результати для ядра, чотирьох серверів (файлової системи, сервери процесів, сервера реінкарнації, інформаційного сервера), п'яти драйверів (жорсткого диска, флоппі-диска, RAM-диска, терміналу, пристрої журналізацію) і програми init показані на рис. 9.
На малюнку можна бачити, що ядро складається з 2947 рядків на мові C і 778 рядків на мові асемблера (для програмування низькорівневих функціональних можливостей, таких як перехоплення переривань і збереження регістрів ЦП при перемиканні процесів). Всього є 3725 рядків коду. І тільки цей код виконується в режимі ядра. Іншим способом вимірювання розміру коду для C-програм є підрахунок числа точок з комою, оскільки багато операторів мови C завершуються крапкою з комою. У коді ядра є 1729 точок з комою. Нарешті, розмір скомпільованій ядра складає 21,312 байт. Це число задає тільки розмір коду (тобто сегмента тексту). Початкові дані (3800 байт) і стек в це число не входять.
Цікаво, що статистика розмірів коду, показана на рис. 9, представляє мінімальну, але функціонуючу операційну систему. Загальний розмір ядерної частини і частини, що працює в режимі користувача, складає всього 18,000 рядків коду, незвичайно мало для POSIX-сумісної операційної системи.
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) і контроль авторизації забезпечують адміністраторам можливість здійснювати суворий контроль над наданням зовнішнім модулям привілеїв, і цей контроль автоматично приводиться у виконання в коді цих модулів. Крім забезпечення авторизації, компілятор грає центральну роль в перевірці того, що код відповідає встановленої політиці. Для цього використовуються як статичні перевірки, так і динамічний інструментарій.