Настроюваність операційних систем

МІНІСТЕРСТВО ОСВІТИ І НАУКИ УКРАЇНИ

КРАСНОДОНСЬКИЙ ПРОМИСЛОВО ЕКОНОМІЧНИЙ КОЛЕДЖ

Реферат з предмету: «Операційні системи»

• На тему: «Настраиваемость операційних систем»

Студента групи 1ОКІСМ-06

Петренко Михайла

Перевірила: Дрокіна Т.М.

Краснодон

2009

Зміст

1. Адаптація, здійснювана людиною

2. Статична адаптація, ініційована проектувальником

3. Динамічна адаптація, ініційована адміністратором

4. Адаптація, ініційована додатком

5. Адаптація з рівня програми

6. Адаптація на рівні ядра

7. Автоматична адаптація

8. Адаптація, здійснювана людиною

Системи в категорії статичній адаптації є, по суті, каркасами операційних систем (framework), які проектувальник може настроювати відповідно до цілей майбутньої ОС. Якщо область додатків, які будуть використовувати створювану ОС, заздалегідь відома, можна створити специфічну ОС, яка буде підтримувати необхідну функціональність і нічого більше. Такий підхід призводить до створення високопродуктивної специфічної ОС. Після компонування такої системи її функціональність і політики фіксовані. Ця форма адаптації застосовується до вбудованих ОС для пристроїв із специфічною функціональністю і більш-менш стабільною діяльністю.

Динамічна адаптація від імені адміністратора можлива в більшості промислових ОС - як під час завантаження, так і під час роботи. Під час завантаження ядра передаються параметри налаштування і конфігураційні установки, під час роботи адміністратор може інсталювати і довантажувати нові модулі ядра, а також відслідковувати параметри продуктивності та налаштовувати операційну систему.

1. Статична адаптація, ініційована проектувальником

В ОС цієї категорії всі системні функції і політики визначаються на етапі проектування, а всі системні сервіси вбудовані в ядро. Основне призначення таких ОС - це специфічна операційна система, можливо навіть для єдиного додатка. Ініціатором адаптації є проектувальник, функціональність і вимоги добре відомі та зрозумілі вже на етапі проектування. Такий підхід веде до збідненим і високопродуктивним системам, в яких може бути присутнім тільки строго обмежена функціональність, а всі сервіси оптимізуються статично під цілком певний додаток. Ясно, що нова функціональність і додатки іншої категорії не можуть підтримуватися такою системою. Це означає, що для кожної програми повинна проектуватися і реалізовуватися нова система, і що один тип пристроїв або комп'ютерів буде підтримувати тільки один додаток (або обмеженого число додатків) [KLM93]. З'являються каркаси (framework) ОС загального призначення, які допомагають уникнути проектування кожної нової ОС з нуля.

Flux OSKit - це система, що складається з каркаса і бібліотечних модулів [FBB97]. Каркас OSKit являє собою набір бібліотек, з яких компонується ядро ОС. Всі компоненти складаються з модулів. Використовуються інтегруючі (glue) верстви, через які здійснюється взаємодія між компонентами та сервісами. Взагалі кажучи, компоненти швидше володіють великим рівнем деталізації, і є, в основному, підсистемами, такими як файлова система, стек мережевого протоколу або набір драйверів пристроїв.

Scout - це каркас для операційних систем, що обслуговують пристрої в мережі [MMO95]. ОС, створена за допомогою Scout складається з модулів, зв'язку між якими представляються у вигляді графа модулів. Цей граф фіксується на етапі проектування. Зміни, пов'язані модулі повинні забезпечувати загальний інтерфейс.

Термін маршрут (path) означає потік даних через систему від джерела вводу / виводу до стоку вводу / виводу. Це поняття можна розглядати як послідовність рішень про маршрутизації всередині модульної системи. Маршрут складається з двох частин - послідовності модулів, які визначають семантику (надійність, безпеку та узгодження за часом), і вимог на ресурси, необхідних для обробки і проходження даних. Маршрути через граф модулів створюються і руйнуються в динаміці. Таке поняття маршруту добре підходить для розподілу ресурсів і оптимізації продуктивності, тому що маршрут забезпечує нелокальний контекст, який не доступний всередині окремого модуля.

У роботі Спатчека і Петерсона [SP97] визначається архітектура безпеки, яка дає можливість проектувальнику встановлювати політику безпеки для операційної системи Scout. Ця архітектура безпеки додає в Scout також численні домени захисту, які інакше перебували б у єдиному адресному просторі.

Choices - це об'єктно-орієнтована, що настроюється ОС, в якій для настроюваність використовуються каркасна технологія і підсистеми [CRJ87, CIR93]. Основне призначення Choices - забезпечити користувачам можливість простої оптимізації та адаптації системи відповідно до поведінкою додатків і робочим навантаженням. Система Choices спроектована як ієрархія каркасів, що підтримують зручну організацію операційної системи по шарах. У Choices каркас складається з набору класів, що представляють системні суті, такі як диски, пам'ять, планувальники і т.д. Різні підсистеми ОС, такі як управління пам'яттю, управління процесами, файлове запам'ятовуючий пристрій, управління винятковими ситуаціями і т.д. створюються безпосередньо з об'єктно-орієнтованих каркасів. Ресурси системи, механізми і політики представляються як екземпляри класів, що належать якоїсь ієрархії класів, де настроювання здійснюється через використання наслідування. Таким чином, специфічна ОС створюється шляхом конкретизації класів і реалізації набору об'єктів, які разом формують дану ОС. Інтерфейсом програми є сукупність об'єктів ядра, що експортуються через рівень захисту додаток / ядро.

Система Choices має слабку формою динамічної адаптації. Коли додатком потрібний який-небудь сервіс, відбувається динамічне завантаження відповідного класу. Таким чином, не можна сказати, що адаптація здійснюється безпосередньо через додаток, до того ж будь-яке можливе поведінка визначається статично.

Pebble є ОС, що базується на компонентах [MBG00]. У той же час Pebble можна назвати як каркасом ОС загального призначення, так і мікроядром для вузла, виконуючого роль порталу (в останньому як вона розглядається в розділі про портал-оріенентірованних ОС). Ця система забезпечує деякий набір абстракцій операційних систем, що реалізуються посвідченими компонентами користувацького рівня. Ці компоненти можуть нарощуватися, заміщатися або розбиватися по шарах, що дозволяє зміненим абстракціям співіснувати з існуючими абстраціямі або повністю замістити їх стандартний набір. Pebble дає можливість створювати модульні ОС з компонентів багаторазового використання. На відміну від подібних систем, системні сервіси не інтегруються в ядро. Вони надаються у вигляді засвідчених серверних компонентів, які виконуються в захищених доменах на рівні користувача.

Система PURE (Portable Universal Runtime Executive) є добре конфігурується системою і надає кошти для підбору необхідної функціональності [Beu99]. Хоча застосування PURE і не обмежена будь-якої областю додатків, все-таки її головне призначення знаходиться в області глибоко вбудованих систем. Проектування PURE засноване на двох концепціях - сімейства програм і об'єктно-орієнтованого підходу. Концепція сімейства програм забезпечує ієрархічну структуру системи, в якій мінімальний набір системних функцій використовується як платформа для реалізаційних або системних розширень. Об'єктно-орієнтований підхід є основою для реалізації. Мінімальним компонентом є клас, тобто систему PURE можна розглядати як бібліотеку класів. Наприклад, компонент, який реалізує управління потоками, складається з 45 класів, збудованих в 14-рівневу ієрархію.

Компоненти PURE впорядковуються в структуру, що складається з ядер і їх розширень. Ядра, так звані CORE (concurrent runtime executive), відповідають за реалізацію мінімального набору системних функцій, керуючих переривань і потоками. Додаткові можливості, звані мінімальними системними розширеннями, додаються в систему за допомогою ядерних розширень, званих NEXT (Nucleus Extension).

Система PURE добре конфігурується і володіє високим рівнем деталізації налаштування.

Вищеописані підходи призводять до гарних результатів для пристроїв або комп'ютерів, функціональність яких відома заздалегідь.

2. Динамічна адаптація, ініційована адміністратором

Цей клас ОС підтримує адаптацію під час розкрутки чи виконання, яку здійснює адміністратор, а іноді і користувач. Така адаптація досягається двома способами.

Перший спосіб - метод завантаження модуля ядра (loadable kernel module) - дає можливість довіреній особі (зазвичай адміністратора або користувачеві з повноваженнями root) завантажити модулі в ядро, таким чином, змінюючи або розширюючи функціональність ОС. Перевага даного методу полягає в його простоті - це нагадує динамічну завантаження класу звичайних додатків. Недоліком є можливість порушення механізмів безпеки системи при додаванні довільного коду в ядро, що може викликати крах системи. Крім того, стабільний стан системи може стати нестабільним після завантаження в ядро зловмисного або просто помилкового модуля.

Другий спосіб - це настройка (tuning) системи. Зазвичай політики ОС параметрізуется, і такі параметри можуть змінюватися, а також адміністратором, або користувачем. Крім того, існують лічильники продуктивності, які допомагають оцінити переваги тієї чи іншої політики, налаштованої через параметри. Перевага цього підходу полягає в тому, що тут не дискредитуються механізми захисту. Недоліком можна вважати той факт, що при такому підході обмежуються широта застосування та рівень деталізації.

Динамічна адаптація від імені адміністратора широко застосовується в усіх промислових ОС (Linux, Solaris, Windows NT і т.д.). Windows 2000 має сотні лічильників продуктивності і відповідних системних змінних. Ядро Linux інтенсивно використовує файли модулі.

Слід зазначити, що контекст і мотиви розширення та адаптованості різні для промислових і дослідницьких ОС. В академічному співтоваристві для ОС головною рушійною силою є продуктивність, часто в не засвідчені (untrusted) контексті. Ініціатор адаптації не може вважатися посвідченим і, отже, цілісність ОС треба захищати. У промислових ОС розширюваність, головним чином, використовується для додавання різних форм функціональності в посвідченні контексті, де ініціатор адаптації є посвідчених (наприклад, адміністратор файлової системи). Метод завантаження модуля ядра використовується для нарощування ядра новими драйверами пристроїв з підтримкою нових файлових систем з новими способами аутентифікації, а також іншими видами функціональності. Модулі поліпшення продуктивності, а також механізмів захисту цілісності дуже рідкісні на практиці. Як наслідок цього, багато дослідні результати по адаптації і нарощуванню не знаходять застосування в промислових ОС.

3. Адаптація, ініційована додатком

Адаптація, ініційована додатком, може проводитися тільки динамічно, і її застосування корисно в ОС загального призначення. У той час як традиційні ОС мали великі труднощі при додаванні нових можливостей, які потрібні, наприклад, для обробки мультимедійних додатків, що налаштовуються ОС швидше адаптувалися в нових умовах. Додаток часто знає свої потреби і може від свого імені інструктувати ОС про необхідну налаштування. Механізми, що надають можливість налаштування від імені програм під час виконання, вводять накладні витрати по продуктивності. Проте мета динамічно настроюваних ОС полягає в тому, щоб досягти кращої продуктивності всієї системи в цілому, дозволяючи налаштування, які призводять до домінуванням переваг над накладними витратами.

4. Адаптація з рівня програми

Розглянемо системи, які дозволяють додаткам настроювати сервіси ОС через введення коду з рівня користувача або непривілейованого рівня. Такі ОС зазвичай називаються мікроядерного, тому що вони структуруються навколо мікроядра. Істинне Мікроядро повинна бути мінімальною, і слід припускати відсутність у ньому будь-яких сервісів або політик.

5. Мікроядерного ОС

Мікроядерний підхід існує досить давно. Однак перші покоління мікроядерного ОС показали результати, далекі від очікуваних. На практиці так і не була реалізована бажана адаптованість через низьку продуктивність і недостатнього рівня деталізації налаштування в ранніх мікроядерного ОС. Спроби поліпшити показники призвели до того, що фундаментальні бібліотеки ОС, такі як файлова система Unix, були знову інтегровані в ядро, що поліпшило продуктивність, але зовсім не допомогло збільшити настроюваністю.

Нове покоління мікроядерного ОС набагато більше відповідає цілям настроюваністю. Проте критичним залишається питання продуктивності, пов'язаний із значною кількістю перемикань між доменами (як між користувальницьким рівнем і ядром, так і між адресними просторами), а також з місцем розташування основної пам'яті [Lie93].

Обраний набір абстракцій, інтегрованих у ядро, істотним чином впливає на продуктивність і гнучкість. Чим менше абстракцій, тим більша гнучкість залишається для додатків. У ядрі повинні бути присутні лише ті абстракції, які необхідні для діяльності самого ядра. Це добре сформульовано в роботах Лідке [Lie95, Lie96] про систему L4 - у ній ядерними абстракціями є адресні простору, потоки, IPC та унікальні ідентифікатори. На основі цих абстракціями в L4 підтримується рекурсивна конструкція адресних просторів - вихідне адресний простір включає всю пам'ять і порти введення / виводу і належить вихідної підсистемі або додатком.

Результатом наближення мікроядерного філософії до її логічної крайності стає ОС, в якій всі системні сервіси виведені за межі ядра і реалізовані у вигляді бібліотек, а саме ядро являє собою просто абстракцію апаратних ресурсів. Такий екстрим реалізований в ОС Exokernel [EKO95]. У ядрі Exokernel відсутні будь-які абстракції ОС і весь його інтерфейс зведений до надбудови над апаратурою. Єдина функція, яка залишена в Exokernel - це виділення, повернення й мультиплексування фізичних ресурсів (сторінок пам'яті, квантів часу процесора, блоків дисків і тому подібне) безпечним чином. Композиція найбільш використовуваних інтерфейсів в Exokernel до цих пір залишається великою проблемою [SSF99].

До мікроядерного ОС можна віднести систему 2K [2K]. Система 2K заснована на компонентах, і її основним завданням є забезпечення налаштовуваного каркаса для підтримки адаптації в мережевому оточенні. Здатність до адаптації регулюється параметрами, такими як пропускна здатність мережі, зв'язність, доступність пам'яті, протоколи взаємодії та компоненти апаратних засобів. ОС 2K грунтується на технології Corba, і в ній для адаптації використовуються дані метауровня і методи, які пропонує рівень ORB (object request broker). Компонент 2K - це динамічно завантажений програмний модуль, який зберігається в спільні бібліотеки (DLL). Слід зазначити, що в системі 2K використовується великий рівень деталізації.

6. Портал-орієнтовані системи

Портал-орієнтована система - це Мікроядро, яке має мінімально можливий код і працює в самому доступному привілейованому режимі. Такі системи володіють доменами захисту, які забезпечують безпеку роботи користувача. Портали використовуються для взаємодії між доменами. Домен захисту складається з набору сторінок і сукупності порталів, причому портали можуть розділяти і сторінки, і портали.

Прикладом портал-орієнтованої системи служить Kea - портал-орієнтоване Мікроядро, яке забезпечує низькорівневі концепції для конструювання високорівневих сервісів [VH96]. Під низькорівневими концепціями розуміються домени (віртуальні адресні простору), звернення доменів один до одного (IPC) та портали. Портал асоційований з певним сервісом - це точка входу для звернення до домену. Кожен сервіс зобов'язаний реєструвати в ядрі свій ідентифікатор, а ядро керує доступом до інтерфейсу цього сервісу. На відміну від справжніх мікроядерного ОС Kea не дає повної свободи для проектування та реалізації сервісів. Та все ж у Kea забезпечується можливість динамічної реконфігурації. При зверненні до сервісу (через його портал) ядро може вирішувати, яку реалізацію вибрати. Наприклад, при використанні файлового сервісу адміністратор може накласти обов'язковий виклик сервісу стиснення даних перед передачею їх файлового сервісу. Більш складна реконфігурація виникає у випадку, коли програма асоціює новий портал з ідентифікатором деякого сервісу. Наприклад, при використанні менеджером віртуальної пам'яті порталу для сервісу заміщення сторінок додаток може змусити його використовувати для своїх сторінок власний сервіс заміщення сторінок. У Kea рівень деталізації адаптації визначається реалізацією сервісів. Якщо менеджер віртуальної пам'яті фіксує політику заміщення сторінок (замість використання для неї порталу, як у прикладі), ніхто не може її змінити, поки не замінить весь сервіс.

У системі SPACE [PBK91] єдиною абстракцією, яка присутня у ядрі, є узагальнення управління винятковими ситуаціями, тобто механізм управління переривань. Якби такий узагальнений механізм управління винятковими ситуаціями міг би бути реалізований на апаратному рівні, операційну систему можна було б вважати "без'ядерної".

Система Pebble [MBG00], так само, як і SPACE, підтримує взаємодію через домени захисту, реалізоване як узагальнення управління переривань. Як і Kea, Pebble здійснює взаємодію доменів через портали і допускає реконфігурацію порталів. Портали реалізуються як узагальнені обробники переривань. Ядро Pebble містить тільки код, який реалізує передачу потоків від одного домену захисту іншому, і невелика кількість функцій підтримки режиму ядра. Як і Exokernel, Pebble віддає реалізацію абстракцій ресурсів на рівень користувача, але, на відміну від Exokernel, Pebble забезпечує сукупність високорівневих абстракцій, які реалізуються компонентами користувацького рівня, що згадувалося в розділі про статичної адаптації, ініційованої проектувальником. Кожен компонент рівня користувача виконується в своєму власному домені захисту, ізольованому апаратними засобами захисту пам'яті.

7. Системи мандатів (Capability Systems)

Системи Fluke і EROS є системами мандатів, які структуровані навколо мікроядра. Тут під мандатом розуміється пара, що складається з ідентифікатора об'єкта і набору санкціонованих операцій над цим об'єктом (його інтерфейс). Прикладом таких мандатів можуть служити дескриптори файлів у UNIX. У системах мандатів кожен процес містить мандати і може здійснювати лише ті операції, які санкціоновані цими мандатами. Мандати - єдині засоби ініціації операцій над об'єктами, і єдині операції, які можуть виконуватися за допомогою мандата - це операції, дозволені цим мандатом. Це означає, що кожен ресурс обслуговується через посередника і повністю інкапсулірованние.

Архітектура вкладених процесів системи Fluke поєднує Мікроядро з віртуальними машинами [FHL96]. Ядро забезпечує базові сервіси і інтерфейс до них. Віртуальні машини використовують цей інтерфейс і реекспортується його на наступний рівень. Кожен шар повністю симулює середовище для вищого рівня - інтерфейс між шарами завжди один і той же, що дозволяє компонувати сервіси за допомогою накладення (stacking) віртуальних машин. Завдяки такому накладенню, або багаторівневому поданням Fluke підтримує вертикальну декомпозицію сервісів, у той час як Мікроядро забезпечує горизонтальну декомпозицію, переносячи традиційну функціональність ядра на сервери користувацького рівня, що розташовані як би поруч (side-by-side).

Необхідність підтримувати узгодженість інтерфейсів між віртуальними машинами вносить великі труднощі при додаванні нових методів або параметрів. Незважаючи на те, що архітектура Pebble близька до архітектури вкладених процесів системи Fluke, Pebble дає можливість розширювати систему з великим рівнем деталізації завдяки механізму заміщення порталів.

Система EROS (Extremely Reliable Operating System) складається з ядра, яке реалізує невеликий набір примітивних мандатний типів [SSF99]. Можливості, які пропонує ядро EROS, відносяться до досить низького рівня. Більшість системних функцій реалізується додатками рівня користувача. Наприклад, ядро EROS безпосередньо надає сторінки дискової пам'яті, але не файлової системи. Файлова абстракція повністю будується на рівні додатків, і файлове програма просто зберігає вміст файлу в адресному просторі, збільшуючи адресний простір в міру необхідності так, щоб воно могло містити весь файл. Обов'язок файлового програми полягає в тому, щоб реалізувати такі операції, як читання і запис, що виконуються над файлом.

Такий метод проектування - створення високорівневих функцій за рахунок об'єднання базових примітивів операційної системи у повторно використовувані компоненти - основна стратегія для створення додатків EROS. Кожен екземпляр компонента реалізується за допомогою окремого процесу, а ядро забезпечує високопродуктивний механізм зв'язку між процесами, що дозволяє ефективно поєднувати ці компоненти. Фактично, вкрай рідко програми EROS працюють із пропонованими об'єктами ядром напряму. Більшість додатків повторно використовує компоненти, що надаються системою, або реалізують нові компоненти, які забезпечують необхідну функцію структурованим способом.

Програми EROS структуруються як захищені, пов'язані мандатами компоненти. Кожен екземпляр компонента працює з індивідуально зазначеними мандатами, визначальними його повноваження. Мандати захищені ядром, як і об'єкти, на які вони вказують. Єдині операції, які можуть виконуватися з мандатом - це операції, що визначаються об'єктом. Завдяки цьому поєднанню захисту і посередництва програма, яка виконує зловмисний код, не може пошкодити систему в цілому або завдати шкоди іншим користувачам, а також не може використовувати привілеї користувача для того, щоб пошкодити інші частини користувальницького середовища. Точно так само, мандати управляють доступом до ресурсів, не дозволяючи зловмисне коду зловживати ресурсами або вивести решту системи з працездатного стану.

8. Операційні системи з кешуванням

Cache Kernel - це ядро операційної системи V + + [CD94]. У цій системі програми виконуються поверх ядер додатків, або в тому ж самому, або в іншому адресному просторі. Ядра додатків реалізують сервіси операційної системи. Вони виконуються на рівні користувача та забезпечують завантаження і розвантаження об'єктів ОЗ (потоків, адресних просторів і інших ядер додатків) відповідно до їх власними політиками. Власне ядро Cache Kernel функціонує як кеш для таких об'єктів. У його інтерфейс включені операції для завантаження і розвантаження системних об'єктів. Для вказівки того, чи повинен деякий об'єкт бути завантажений або розвантажений, використовуються сигнали

9. Рефлективні операційні системи

У рефлективних операційних системах вводиться явна парадигма, яка дає можливість додаткам динамічно настроювати своє середовище виконання. Додаток повинен бути явно структуроване як сукупність об'єктів, а системні сервіси представляються у вигляді сукупності мета-об'єктів.

MetaOS - це об'єктно-орієнтована ОС, заснована на використанні мови Java [HPM98]. Архітектура цієї ОС складається з трьох рівнів. Об'єкти додатків розташовуються на базовому рівні. На рівні нижче знаходяться мета-об'єкти, динамічно згруповано в мета-простору. Кожне мета-простір підтримує ряд програм зі схожими вимогами. Цей рівень носить назву мета-рівня. У самому низу знаходиться мета-мета-рівень, який стиснуто до єдиного мета-простору - головного (master) мета-простору. Це мета-простір розподіляє ресурси відповідно до динамічно заміщаються політиці. У MetaOS використовується відкрита реалізація для підтримки визначення і конструювання об'єктів, мета-об'єктів і їх інтерфейсів. Через ці інтерфейси мета-простору можуть бути адаптовані і розширені динамічним і безпечним чином. Коли додаток починає виконуватися, воно обирає найбільш підходяще доступне мета-простір, в якому вона може ініціювати ряд змін з великим рівнем деталізації. Якщо цього виявиться недостатньо, додаток може клонувати мета-простір і мігрувати в нього. Після цього додаток буде мати повний контроль над мета-простором і, таким чином, над власною середовищем виконання.

10. Адаптація на рівні ядра

Системи, що допускають адаптацію на рівні ядра, звичайно називаються нарощуваними ядрами (extensible kernels). У цих системах застосовуються передові технології, які гарантують цілісність ядра. Нарощувані ядра беруть код користувача і виконують його в привілейованому безпечному режимі, динамічно змінюючи поведінку ядра. Ця технологія дозволяє позбутися від перемикань між режимами користувача і ядра і між адресними просторами. Оскільки кодом, який вводиться додатком у ядро, не можна довіряти, вирішальним чинником для нарощуваних ядер стає застосовуваний механізм безпеки.

Політика безпеки в ОС проводиться в життя через верифікацію або через захист (protection). Захист намагається гарантувати коректне поведінку програми після його інсталяції або обмежити наслідки завданої шкоди. Захист досягається як апаратними, так і програмними засобами.

Захист за допомогою апаратури зазвичай здійснюється в мікроядра. У таких системах апаратні засоби гарантують, що налаштування системи, що відбуваються на рівні користувача, ніколи не зможуть модифікувати ядро.

Верифікація гарантує коректна поведінка розширення до інсталяції і розгортання. При обговоренні ОС розглядаються два види верифікації - верифікація джерела і верифікація поведінки.

При верифікації джерела код вважається безпечним, якщо він введений у систему засвідченої стороною (наприклад, адміністратором). Така практика застосовується в промислових ОС (UNIX, Windows NT), де такий підхід носить назву методу завантаження модуля ядра. Завантаження модуля може виконуватися як адміністратором, так і додатком з правами root, або навіть додатками з правами користувача, якому дозволена така завантаження, якщо він є засвідченої третьою стороною (наприклад, виробник даної ОС).

При верифікації поведінки ОС намагається проаналізувати, чи дійсно даний код веде себе належним чином. Дуже приваблива автоматична верифікація поведінки, але її важко здійснювати.

11. Програмна захист

У системах з нарощуваними ядрами покладатися на апаратну захист неможливо, тому що розширення (ненадійний код) має ті ж повноваження, що і ядро. Тут необхідно застосовувати програмну захист. Найбільш поширеними підходами до програмної захисту є: програмна локалізація несправностей і безпечні мови.

Програмна локалізація несправностей забезпечує захист пам'яті в єдиному адресному просторі (наприклад, всередині ядра) [WLA93]. Вона здійснюється у два етапи. Спочатку ненадійний код завантажується у власний ізольований домен (так званий "несправний" домен), який є областю пам'яті, логічно розділеної з ядром. Потім код модифікується таким чином, що з нього не можна здійснити запис або виконати команду переходу за межі цього ізольованого домену. Одним із способів реалізації цього підходу є sandboxing (механізм забезпечення безпеки підкачали з мережі або отриманих по електронній пошті програм, що передбачає ізоляцію на час виконання завантаження коду в обмежену середу - "пісочницю"). Ізольований домен складається з сегменту коду та сегменту даних. У старших бітах адреси міститься ідентифікатор сегмента. Перед кожною ненадійною інструкцією в сегменті коду вставляються інструкції, які записують у старші біти адреси в ненадійною інструкції ідентифікатор ізольованого сегменту, не даючи їй можливості звернутися за адресою за межі цього домену. Взаємодія між ізольованими сегментами здійснюється через RPC-інтерфейс (remote procedure calls).

У системі VINO [SS97] також застосовується програмна локалізація несправностей. У цій системі кожна розширення в ядрі має свої власні стек і область пам'яті. Захист пам'яті гарантує програмна локалізація несправностей. Крім того, VINO використовує систему полегшених транзакцій для управління виконанням розширень та використанням ресурсів. Нарощуваність в VINO можна здійснити двома способами:

додаток може замінити реалізацію методу деякого об'єкту ядра (ресурсу), якщо це дозволено, - це дозволяє змінювати стандартну поведінку ресурсів, додаток може зареєструвати в ядрі обробник якогось події, такого як підключення в мережі до конкретного порту, що дозволяє інсталювати в ядрі нові сервіси.

До недоліків методу програмної локалізації несправностей можна віднести ту обставину, що кожного разу перед виконанням ненадійною інструкції повинні виконуватися накладні інструкції.

Іншим поширеним способом збереження цілісності ядра є накладення обмежень на абстракції мови програмування. Найбільш цікавим механізмом такого типу є метод перевірки типів (type checking), який має на увазі, що безпечні мови є типізовані і володіють типовий безпекою.

Безпечні мови, широко використовуються у дослідницьких проектах, - це Modula-3, Java та ML. Мова ML має формальну типову систему, відому як систему Hindley-Milner, і дає можливість здійснювати статичну перевірку типів. Мови Modula-3 і Java мають менший формалізмом, тому, щоб гарантувати в них політику безпеки, необхідно виконувати численні перевірки типів під час виконання. Однак ML, як декларативний мову, забезпечує недостатню ефективність під час виконання.

Система SPIN заснована на мові Modula-3 [BSP95]. Всі взаємодії між додатком і ядром здійснюються за допомогою розширень. Кожне розширення зв'язується з подією. Розширення повинна бути зареєстрована диспетчером, який інсталює розширення і передає події розширень. З окремим подією може бути пов'язано декілька розширень. Розширення заміщаються або додаються диспетчером. Modula-3, в основному, використовується для гарантування захисту пам'яті. Додаткові обмеження накладаються диспетчером і стандартними розширеннями. Динамічний компонувальник гарантує, що розширення бачить тільки санкціоновані події.

Очевидним недоліком таких систем є їх жорстка прив'язаність до певної мови - весь системний код і розширення повинні бути написані на цій мові. Ще один недолік полягає в тому, що політика безпеки фіксована і визначається обраним мовою. Крім того, численні перевірки під час виконання сильно знижують продуктивність системи.

12. Автоматична верифікація

Метод автоматичної верифікації заснований на представленні коду в певному форматі, званому PCC (Proof-Carrying Code) [Nec97]. PCC-модуль містить формальний доказ відповідності коду даній політиці безпеки. Істинність докази гарантує безпеку коду, і програмний модуль може виконуватися без перевірок під час виконання. Політика безпеки ядра описується за допомогою аксіом і правил виводу в доказах, а також формулюється у вигляді предикатів логіки першого порядку для кожної інструкції, в яких вказується, за яких обставин виконання кожної інструкції буде залишатися безпечним. Програма використовує предикати політики безпеки для обчислення предиката безпеки. Потім доводиться безпеку цього предиката за правилами логіки першого порядку з використанням аксіом і правил виводу політики безпеки. Доказ приєднується до розширення. Ядро, в свою чергу, також обчислює предикат безпеки і перевіряє істинність асоційованого докази для цього предиката. Перевірка достовірності може бути зроблена через просту та ефективну перевірку типів (type checking).

Незважаючи на привабливість цього підходу, застосовність його поки залишається проблемою. Великі труднощі виникають при спробах автоматизувати генерацію доказів і використовувати докази для мов високого рівня.

13. Автоматична адаптація

Автоматичною адаптацією є адаптація, ініційована самою ОС. Можна розглядати переносимість, реалізовану через умовну компіляцію, як статичну форму автоматичної адаптації. Виявивши, на якій платформі операційна система повинна бути скомпонована, система сама здатна конфігуруватися, наприклад, за допомогою C препроцесора.

Найбільш цікаву категорію складають ОС, які самі динамічно або статично адаптуються до виконуваних додатків. З цією метою ОС повинна бути здатна відстежувати і аналізувати програми і автоматично змінювати свою поведінку, щоб підтримувати програми найкращим чином. Промислові ОС зазвичай підтримують обмежену форму динамічної автоматичної адаптації в специфічних і добре зрозумілих підсистемах, наприклад, у файловій системі, яка може контролювати поведінку користувальницьких програм для оптимізації своєї продуктивності.

Створення автоматичної динамічно настроюваної ОС загального призначення можна розглядати як кінцеву мету досліджень в області настроюваність ОС. Однак у зв'язку з труднощами, що виникають при компонуванні таких систем, поки ще нічого не чути про автоматичні системах у повному сенсі цього слова. Поки що можна говорити тільки про кілька проектів, що обговорювалися далі.

Система Synthetix призначена для забезпечення спеціалізованих реалізацій сервісів операційної системи, що генеруються під час виконання, на підставі часткової оцінки [CBK96]. Ступінь деталізації і широта настроюваність обмежені - проектувальник вирішує, який сервіс може бути конкретизований і вибирає параметри конкретизації. Параметри сервісу вводяться за допомогою інваріантів, з якими пов'язані блоки захисту (guards). Після перевірки коректності параметрів модуль сервісу заміщається реалізацією з новими параметрами. Наприклад, системний виклик відкриття файлу може повертати конкретизований код, що забезпечує читання файлу. Такий код міг би мати інваріанти, такі як розмір блоку на диску, послідовний доступ, монопольний доступ і т.п. Коли той же самий файл пізніше відкривається іншим додатком, інваріант монопольного доступу стає некоректним через порушення блоку захисту, пов'язаного з системним викликом відкриття файлу.

Автоматичний підхід до настроюваність досліджувався в проекті VINO [SS97], яке вже розглядалося вище, однак цей підхід у VINO не був реалізований. На думку авторів для здійснення автоматичної адаптації поведінки системи необхідно отримувати відомості з наступних трьох джерел:

· періодична статистика від кожної підсистеми VINO,

· спеціалізований компілятор,

· траси і журнали, які реєструють вхідні запити і вироблені результати.

Вся інформація збирається в реальних обставинах, під час виконання програми. Потім ця інформація аналізується з метою виявлення надзвичайних обставин - наприклад, ситуацій, коли споживання ресурсів перевищує очікувану норму. У таких ситуаціях адаптація проводиться згідно відомим евристики. Наприклад, нехай якесь додаток інтенсивно гортає сторінки; тоді створюються траси для запитуваних сторінок. Результуючі траси досліджуються на предмет збігу з добре відомими моделями підкачки сторінок. Якщо така модель знаходиться, інсталюється відповідний алгоритм. Проект VINO цікавий тим, що в ньому використовуються евристики для добре відомих випадків. На відміну від системи Synthetix, в якій адаптуються тільки функції і параметри, визначені проектувальником, VINO підтримує механізм, за допомогою якого система могла б розробляти і тестувати нові алгоритми для знову виникаючих проблем.