Реферат: Побудова надійних операційних систем, що допускають наявність ненадійних драйверів пристроїв
Реферат: Побудова надійних операційних систем, що допускають наявність ненадійних драйверів пристроїв
Реферат
На тему: «Побудова надійних операційних систем, що допускають наявність ненадійних драйверів пристроїв»
Введення
Найбільш гострою проблемою багатьох користувачів є ненадійність комп'ютерів.
Дослідники у галузі комп'ютерної науки звикли до регулярних збоїв комп'ютерів і до необхідності через кожні кілька місяців встановлювати патчі програмного забезпечення. Проте переважна більшість користувачів вважає це відсутність надійност неприйнятним. Їхня внутрішня модель роботи електронного пристрою ґрунтується на досвіді використання телевізорів і відеомагнітофонів: ви купуєте пристрій, підключаєте його до мережі, і воно бездоганно працює протягом 10 років. Ніяких відмов, ніяких регулярних оновлень програмного забезпечення, ніяких газетних сторій про виявлення новітніх представників нескінченної низки вірусів. Щоб зробити комп'ютерні системи більш схожими на телевізори, ми ставимо за мету свого дослідження вдосконалення надійності комп'ютерних систем, і починаємо з операційних систем.
1. Чому у систем трапляються відмови?
Основна причина аварійних відмов операційних систем криється у двох принципових дефекти розробки, властивих всім цим системам: наявність занадто великого числа привілеїв і відсутність адекватної ізоляції збоїв. Практично всі операційн системи складаються з численних модулів, скомпонованих в одному адресному просторі і утворюють єдину бінарну програму, яка виконується в режимі ядра. Помилка в будь-якому модулі може легко призвести до руйнування структур даних в будь-якому іншому, не пов'язаним з ним модулі і до миттєвого виходу системи з ладу. Причиною, за якою всі модулі компонуються в єдиний адресний простір без підтримки будь-якої захисту між модулями, є Фаустова угода розробників: покращена продуктивність за ціну більшого числа відмов системи. Нижче ми оцінимо вартість цього компромісу.
Тісно пов'язаний питання відноситься до першопричину аварійних відмов. Адже якби кожен модуль був бездоганним, то не виникала б потреба в ізоляції збоїв між модулями, оскільки не було б самих збоїв. Ми стверджуємо, що більша частина збоїв виникає через помилки програмування, внаслідок надмірної складност використання чужого коду. Дослідження показують, що в програмному забезпеченн в середньому міститься від однієї до шістнадцяти помилок на тисячу рядків коду [27, 22, 2], і що верхня межа цього діапазону явно занижена, оскільки враховувалися тільки ті помилки, які, врешті-решт, вдавалося виявити. Очевидним висновком є те, що в більшому обсязі коду міститься більша кількість помилок. У міру розвитку програмного забезпечення в кожній його новій версії з'являється все більше можливостей (і, відповідно, більший об'єм коду), і часто нова версія менш надійною, ніж попередня. У [22] показано, що число помилок на тисячу рядків коду прагне до стабілізації у міру зростання числа випущених версій, але асимптотично цей показник відрізняється від нуля.
Наявність деяких з цих помилок дозволяє зловмисникам застосовувати віруси і черв'яки для зараження і пошкодження системи. Так що деякі нібито наявні проблеми «безпеки» в принципі не мають нічого спільного з порушеннями заходів безпеки (наприклад, дефектними криптографічними алгоритмами або нестійкими протоколами авторизації), а викликаються лише помилками в коді програм (наприклад, переповнення буферів дозволяють виконувати впроваджений код). Коли в цій статт ми говоримо про «надійності», ми маємо на увазі й те, що часто називають «безпекою», – неавторизований доступ внаслідок помилки в коді програми.
Друга проблема полягає в привнесення в операційну систему чужого коду. Найбільш досвідчені користувачі ніколи б не дозволили сторонньої організації вставити незнайомий код в ядро операційної системи, хоча, коли вони купують нове периферійне пристрій і інсталюють відповідний драйвер, вони саме це й роблять. Драйвери пристроїв звичайно пишуться програмістами, що працюють на виробників периферійних пристроїв, і контроль якості їх продукції звичайно нижче, ніж у постачальників операційних систем. У тих випадках, коли драйвер відноситься до open-source, його часто пише благонамірений, але не обов'язково досвідчений доброволець, і контроль якості забезпечується на ще більш низькому рівні. Наприклад, в Linux частота появи помилок в драйверах пристроїв від трьох до семи разів вище, ніж в інших частинах ядра [7]. Навіть компанія Microsoft, у якої є стимули та ресурси для застосування більш щільного контролю якості, не може добитися набагато кращих результатів: 85% всіх аварійних відмов Windows XP обумовлюється наявністю помилок у коді драйверів.
Останнім часом з'явилися публікації про родинні роботах, присвячених ізоляції драйверів пристроїв з використанням апаратури MMU [26] і віртуальних машин [19]. Ц методи концентруються на вирішенні проблем у успадкованих операційних системах; ми обговоримо їх у розд. 6. На відміну від цього, при застосуванні нашого підходу надійність досягається шляхом розробки нової полегшеної операційної системи.
2. Рішення: правильна ізоляція збоїв
Протягом десятиліть як перевірений методу оперування кодом, що не заслуговує довіри, використовувалося розміщення його в окремому процесі та виконання в режим користувача. Одним з ключових спостережень, отриманих у дослідженні, якому присвячена ця стаття, є те, що потужним засобом підвищення надійност операційної системи є виконання кожного драйвера у вигляді окремого процесу в режимі користувача з мінімальними необхідними привілеями. Таким чином, код, потенційно містить помилки, ізолю, і помилка, скажімо, в драйвері принтера може призвести до припинення друку, але не до запису перекручених даних у будь-як важливі структури даних ядра і виходу системи з ладу.
У цій статті ми проводимо ретельне відмінність між крахом операційної системи, після якого потрібне перезавантаження комп'ютера, і збоєм або відмовою сервера або драйвера, після якого в нашій системі перезавантаження не потрібно. У багатьох випадках дефектний драйвер, що виконується в режимі користувача, може бути вилучений і замінений без потреби в перезапуску інших частин операційно системи, які виконуються в режимі користувача.
Ми не розраховуємо на те, що незабаром з'явиться код, вільний від помилок, а якщо з'явиться, то, звичайно, не в операційних системах, які зазвичай пишуться на C або C + +. На жаль, у програмах, написаних на цих мовах, інтенсивно використовуються покажчики, рясний джерело помилок. Тому наш підхід заснований на ідеях модульності та ізоляції збоїв. Шляхом розбиття системи на велику кількість ізольованих модулів, кожен з яких виконується в окремому процесі в режимі користувача, нам вдалося скоротити частину системи, виконувану в режим ядра, до абсолютного мінімуму і запобігти поширенню збоїв, що виникають в інших модулях. Зменшення розмірів ядра значно скорочує число помилок, які воно, ймовірно, має містити. Малий розмір також дозволяє знизити рівень складност ядра і полегшити його розуміння, що також сприяє надійності. Тому ми пішли максими Сент-Екзюпері і зробили ядро настільки невеликим, наскільки це дозволяють людські можливості: менше 3800 рядків коду.
Одне з зауважень, постійно виникає з приводу таких розробок мінімального ядра, стосується уповільнення роботи системи через додаткові перемикань контексту копіювання даних, яке потрібно для забезпечення комунікацій різних моделей, як виконуються в користувацькому адресному просторі. Це побоювання, в основному, снує з історичних причин, і ми стверджуємо, що ці причини, більшою частиною, наразі відсутні. По-перше, результати нових досліджень показують, що розробка мінімального ядра не обов'язково завдає шкоди ефективності [3, 23, 15]. Зменшення розмірів ядра при наявності розумних протоколів взаємодії серверів допомагає обмежити масштабність проблеми ефективності. По-друге, значне зростання потужності комп'ютерів в останнє десятиліття істотно послаблю проблему гарантованої продуктивності, що виникає при модульної розробці. По-третє, ми вважаємо, що настає час, коли велика частина користувачів з задоволенням пожертвує деякої ефективністю задля поліпшеної надійності.
Детальний обговорення ефективності нашої системи ми представляємо в розд. 5. Однак тут ми коротко згадаємо три попередніх показника ефективності на підтримку нашого доводу про те, що системи з мінімальним ядром не обов'язково повинні бути повільними. По-перше, виміряний час виконання найпростішого системного виклику getpid складає 1.01 мсек на процесорі Athlon з частотою 2.2 Ггц. Це означає, що програма, яка виробляє 10000 системних викликів в секунду, витрачає на перемикання контексту всього 1% часу ЦП, а 10000 системних викликів в секунду виробляють лише деякі програми. По-друге, наша система здатна протягом 4 секунд повністю провести свою компоновку, включаючи ядро і всі частини, що виконуються в режим користувача (при цьому компілюються 123 файлу і відбувається 11 редагувань зв'язків). По-третє, час початкового завантаження системи з моменту виходу з монітора багатоваріантної завантаження до видачі запрошення до входу в систему становить менше 5 секунд. Після цього операційна система, повністю сумісна з POSIX, готова до використання.
3. Вклад цієї статті
Дослідження, результати якого описуються в цій статті, було направлено на вироблення відповіді на таке запитання: як уникнути ситуацій, в яких серйозна помилка в драйвері пристрою (наприклад, використання невірного покажчика або наявність нескінченного циклу) призводить до аварійного відмови або зависання вс операційної системи?
Наш підхід полягав у розробці надійної мультисерверного операційної системи поверх крихітного ядра, що не містить будь-якого зовнішнього, ненадійного коду. Для забезпечення належної ізоляції збоїв кожен сервер і драйвер виконується в режимі користувача в рамках окремого процесу. Крім того, ми додали механізми для відновлення після виникнення поширених збоїв. Ми детально описуємо засоби підтримки надійності і пояснюємо, чому вони відсутні у традиційних монолітних операційних системах. Ми також обговорюємо отримані показники ефективност системи і показуємо, що кошти підтримки надійності сповільнюють систему на 5–10%, але роблять її стійкою до наявності невірних покажчиків, нескінченних циклів нших помилок, які призвели б до аварійного відмови або зависання традиційних операційних систем.
Хоча ні один з окремих аспектів нашого підходу (ядра невеликого розміру, драйвери пристроїв, які виконуються в режимі користувача, або мультисерверного системи) не є новим, ніхто раніше не збирав до купи всі ці частини для побудови невеликий, гнучкою, модульної UNIX-подібної системи, що є набагато більш відмовостійкої, ніж звичайні системи сімейства UNIX, і втрачає тільки 5–10% ефективност порівняно з нашою базовою системою, яка містить драйвери в ядрі.
Крім того, наш підхід у корені відрізняється від інших аналогічних робіт, оскільки ми не фокусуємося на масових операційних системах. Замість цього ми отримуємо надійність на основі нової, полегшеною архітектури. Замість того щоб додавати допоміжний код, який підвищує надійність ненадійних систем, ми розщеплю операційну систему на невеликі компоненти й досягаємо надійності за рахунок модульності системи. Хоча наші методи незастосовні до успадкованим операційним системам, ми сподіваємося, що вони допоможуть зробити більш надійними майбутн операційні системи.
Ми починаємо статтю з порівняння нашої розробки зі структурами інших операційних систем (розд. 2) і далі переходимо до спільному обговоренню засобів підтримки надійності нашої системи (розд. 3). Потім ми аналізуємо надійність (розд. 4) ефективність (розд. 5) системи на основі реальних вимірів. У кінці статті ми аналізуємо деякі суміжні роботи (розд. 6) і представляємо свої висновки (розд. 7).
4. Розробка операційної системи
Цей проект присвячений побудові більш надійної операційної системи. Перш ніж докладно описувати свою розробку, ми коротко обговоримо, яким чином вибір структури операційної системи може безпосередньо впливати на її надійність. У своїх цілях ми будемо проводити розходження між двома структурами операційних систем: монолітними системами і системами з мінімальним ядром. Існують і інші типи операційних систем, такі як екзоядра [10] і віртуальні машини [24]. Вони не мають безпосереднього відношення до даної статті, але ми повернемося до них у розд. 6.
Проблеми монолітних систем
Як показано на рис. 1, у стандартній монолітної системі ядро містить вс операційну систему, скомпоновану в єдиному адресному просторі і виконувану в режимі ядра. Ядро може бути структуровано на компоненти, або модулі, показан на малюнку у вигляді прямокутників з пунктирними сторонами, але між компонентами відсутні захисні кордону. На відміну від цього, прямокутники із суцільними сторонами відповідають окремим процесам, що виконуються в режим користувача; кожен з цих процесів виконується в окремому адресному просторі, що захищається апаратурою MMU (Memory Management Unit, пристрій управління пам'яттю).
З монолітними операційними системами пов'язана низка проблем, властивих їх архітектурі. Хоча деякі з цих проблем вже згадувалися у введенні, ми наведемо тут їх зведення:
1. Відсутня належна ізоляція збоїв.
2. Весь код виконується на найвищому рівні привілейованості.
3. Величезний розмір коду припускає наявність численних помилок.
4. У ядрі присутній ненадійний сторонній код.
5. Складність систем утрудня х супровід.
Цей список властивостей ставить під сумнів надійність монолітних систем. Важливо розуміти, що ці властивості виникають не унаслідок поганої реалізації, а являють собою фундаментальні проблеми, пов'язані з архітектурою операційно системи.
Передбачається коректність ядра, у той час, як тільки лише його розмір означає, що воно ма містити численні помилки [27, 22, 2]. Більш того, для всіх операційних систем, в яких код виконується на найвищому рівні привілейованості, і не забезпечується належне стримування поширення збоїв, будь-яка помилка може стати фатальною. Наприклад, неправильно працюючий драйвер пристрою, наданий стороннім розробником, може легко зруйнувати ключові структури даних і вивести з ладу всю систему. Реальність такої загрози випливає з того спостереження, що аварійні відмови більшості операційних систем трапляються з вини драйверів пристроїв [7, 25]. Додатковою проблемою є те, що величезний розмір монолітних ядер робить їх дуже складними і важко розуміти. Без загального розуміння ядра навіть досвідчений програміст може легко внести помилки за рахунок недостатньої поінформованост про побічні ефекти своїх дій.
Системи з мінімальним ядром
На ншому полюсі знаходиться мінімальне ядро, що містить лише чистий механізм ніякої політики. Мінімальна ядро включає обробники переривань, механізм для запуску та зупинки процесів (шляхом завантаження регістрів MMU і ЦП), планувальник і механізм підтримки міжпроцесної комунікацій; в ідеальному випадку більше в ядро не входить нічого. Підтримка функціональних можливостей стандартної операційної системи, представлених у монолітному ядрі, переміщається в користувальницьке адресний простір, і відповідний код більше не виконується на найбільш привілейованому рівні.
Поверх мінімального ядра можливі різні організації операційної системи. Одним з варіантів є виконання всієї операційної системи в одному сервері в режим користувача, але в такій архітектурі існують ті ж проблеми, що і в монолітній системі, і помилки, як і раніше можуть призвести до аварійного відмови вс операційної системи, що виконується в режимі користувача. У розд. 6 ми обговоримо деякі роботи в цій області.
Кращим рішенням є виконання кожного ненадійного модуля в режимі користувача в окремому процесі, ізольованому від інших процесів. Ми до крайності захопилися цією ідеєю повністю роздрібнили свою систему, як показано на рис. 2. Ус функціональні компоненти операційної системи, такі як драйвери пристроїв, файлова система, сервер мережі та високорівневе управління пам'яттю, виконуються як окремі процеси в режимі користувача у власному адресному просторі. Цю модель можна визначити, як мультисерверного операційну систему.
З логічної точки зору наші користувальницькі процеси можна розбити на три рівні, хоча з точки зору ядра всі вони є всього лише процесами. Найнижчий рівень процесів, які виконуються в режимі користувача, займають драйвери пристроїв, кожен з яких керує деякими пристроєм. Ми реалізували драйвери для інтерфейсу IDE, гнучких і жорстких дисків, клавіатури, дисплеїв, аудіо-пристроїв, принтерів і різних карт Ethernet. Вище рівня драйверів знаходяться серверн процеси. У їх число входять файловий сервер, сервер процесів, мережевий сервер, нформаційний сервер, сервер реінкарнації та інші. Над рівнем серверів виконуються звичайні користувальницькі процеси, включаючи різні інтерпретатори shell, компілятори, утиліти та прикладні програми. Не рахуючи невеликого числа виключень, сервери і драйвери є нормальними для користувача процесами.
