Сучасні концепції і технології проектування операційних систем.

 

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

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

· Розширюваність. Код повинен бути написаний так, щоб можна було легко внести доповнення і зміни, якщо це буде потрібно, і не порушити цілісність системи.

· Переносимість. Код повинен легко переноситися з процесора одного типу на процесор іншого типу і з апаратної платформи (яка включає разом з типом процесора і спосіб організації всієї апаратури комп'ютера) одного типу на апаратну платформу іншого типу.

· Надійність і відмовостійкість. Система повинна бути захищена як від внутрішніх, так і від зовнішніх помилок, збоїв і відмов. Її дії повинні бути завжди передбаченими, а застосування не повинні бути в змозі завдавати шкоди ОС.

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

· Безпека. ОС повинна володіти засобами захисту ресурсів одних користувачів від інших.

· Продуктивність. Система повинна володіти настільки хорошою швидкодією і часом реакції, наскільки це дозволяє апаратна платформа.

Розглянемо детальніше деякі з цих вимог.

Розширюваність

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

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

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

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

Засоби виклику видалених процедур (RPC) також дають можливість розширити функціональні можливості ОС. Нові програмні процедури можуть бути додані в будь-яку машину мережі і негайно поступити в розпорядження прикладних програм на інших машинах мережі.

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

Переносимість

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

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

По-друге, слід врахувати, в яке фізичне оточення програма повинна бути перенесена. Різна апаратура вимагає різних рішень при створенні ОС. Наприклад, ОС, побудована на 32-бітових адресах, не може бути перенесена на машину з 16-бітовими адресами (хіба що з величезними труднощами).

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

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

Для легкого перенесення ОС при її розробці повинні бути дотримані наступні вимоги:

· Переносима мова високого рівня. Більшість переносимих ОС написана на мові З (стандарт ANSI X3.159-1989). Розробники вибирають З тому, що він стандартизован, і тому, що С-компілятори широко доступні. Асемблер використовується тільки для тих частин системи, які повинні безпосередньо взаємодіяти з апаратурою (наприклад, обробник переривань) або для частин, які вимагають максимальної швидкості (наприклад, цілочисельна арифметика підвищеної точності). Проте нестерпний код повинен бути ретельно ізольований усередині тих компонентів, де він використовується.

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

· Ізоляція платформи. Залежність від платформи полягає у відмінностях між робочими станціями різних виробників, побудованими на одному і тому ж процесорі (наприклад, MIPS R4000). Повинен бути введений програмний рівень, що абстрагує апаратуру (кеші, контроллери переривань введення-висновку і т. п.) разом з шаром низькорівневих програм так, щоб високорівневий код не потребував зміни при перенесенні з однієї платформи на іншу.

Сумісність

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

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

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

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

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

Набагато складніше досягти двійкової сумісності між процесорами, заснованими на різній архітектурі. Для того, щоб один комп'ютер виконував програми іншого (наприклад, DOS-програму на Mac), цей комп'ютер повинен працювати з машинними командами, які йому спочатку незрозумілі. Наприклад, процесор типу 680x0 на Mac повинен виконувати двійковий код, призначений для процесора 80x86 в РС. Процесор 80x86 має свої власні дешифратор команд, регістри і внутрішню архітектуру. Процесор 680x0 не розуміє двійковий код 80x86, тому він повинен вибрати кожну команду, декодувати її, щоб визначити, для чого вона призначена, а потім виконати еквівалентну підпрограму, написану для 680x0. Оскільки до того ж у 680x0 немає в точності таких же регістрів, прапорів і внутрішнього арифметико-логічного устрою, як в 80x86, він повинен імітувати всі ці елементи з використанням своїх регістрів або пам'яті. І він повинен ретельно відтворювати результати кожної команди, що вимагає спеціально написаних підпрограм для 680x0, що гарантують, що стан емульованих регістрів і прапорів після виконання кожної команди буде в точності таким же, як і на реальному 80x86.

Це проста, але дуже повільна робота, оскільки мікрокод усередині процесора 80x86 виконується на значно більш швидкодіючому рівні, ніж що емулюють його зовнішні команди 680x0. За час виконання однієї команди 80x86 на 680x0, реальний 80x86 може виконати десятки команд. Отже, якщо процесор, що проводить емуляцію, не настільки швидкий, щоб компенсувати всі втрати при емуляції, то програми, що виконуються під емуляцією, будуть дуже повільними.

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

Відповідність стандартам POSIX також є засобом забезпечення сумісності програмних і призначених для користувача інтерфейсів. У другій половині 80-х урядові агентства США почали розробляти POSIX як стандарти на устаткування, що поставлялося, при укладенні урядових контрактів в комп'ютерній області. POSIX - це "інтерфейс переносимої ОС, що базується на UNIX". POSIX - збори міжнародних стандартів інтерфейсів ОС в стилі UNIX. Використання стандарту POSIX (IEEE стандарт 1003.1 - 1988) дозволяє створювати програми стилі UNIX, які можуть легко переноситися з однієї системи в іншу.

Безпека

На додаток до стандарту POSIX уряд США також визначив вимоги комп'ютерної безпеки для застосувань, використовуваних урядом. Багато хто з цих вимог є бажаними властивостями для будь-якої розрахованої на багато користувачів системи. Правила безпеки визначають такі властивості, як захист ресурсів одного користувача від інших і встановлення квот по ресурсах для запобігання захопленню одним користувачем всіх системних ресурсів (таких як пам'ять).

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

Основи стандартів в області безпеки були закладені "Критеріями оцінки надійних комп'ютерних систем". Цей документ, виданий в США в 1983 році національним центром комп'ютерної безпеки (NCSC - National Computer Security Center), часто називають Оранжевою Книгою.

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

Ієрархія рівнів безпеки, приведена в Оранжевій Книзі, позначає нижчий рівень безпеки як D, а вищий - як А.

· У клас D потрапляють системи, оцінка яких виявила їх невідповідність вимогам всіх інших класів.

· Основними властивостями, характерними для С-систем, є: наявність підсистеми обліку подій, пов'язаних з безпекою, і виборчий контроль доступу. Рівень З ділиться на 2 підрівні: рівень С1, що забезпечує захист даних від помилок користувачів, але не від дій зловмисників, і строгіший рівень С2. На рівні С2 повинні бути присутніми засоби секретного входу, що забезпечують ідентифікацію користувачів шляхом введення унікального імені і пароля перед тим, як їм буде дозволений доступ до системи. Виборчий контроль доступу, потрібний на цьому рівні дозволяє власникові ресурсу визначити, хто має доступ до ресурсу і що він може з ним робити. Власник робить це шляхом прав доступу користувачеві або групі користувачів, що надаються. Засоби обліку і спостереження (auditing) - забезпечують можливість виявити і зафіксувати важливі події, пов'язані з безпекою, або будь-які спроби створити, дістати доступ або видалити системні ресурси. Захист пам'яті - полягає в тому, що пам'ять ініціалізувалася перед тим, як повторно використовується. На цьому рівні система не захищена від помилок користувача, але поведінка його може бути проконтрольована по записах в журналі, залишених засобами спостереження і аудитинга.

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

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

Різні комерційні структури (наприклад, банки) особливо виділяють необхідність облікової служби, аналогічної тій, що пропонують державні рекомендації С2. Будь-яка діяльність, пов'язана з безпекою, може бути відстежена і тим самим врахована. Це якраз те, що вимагає С2 і те, що зазвичай потрібне банкам. Проте, комерційні користувачі, як правило, не хочуть розплачуватися продуктивністю за підвищений рівень безпеки. А-уровень безпеки займає своїми механізмами, що управляють, до 90% процесорного часу. Безпечніші системи не тільки знижують ефективність, але і істотно обмежують число доступних прикладних пакетів, які відповідним чином можуть виконуватися в подібній системі. Наприклад для ОС Solaris (версія UNIX) є декілька тисяч застосувань, а для її аналога В-уровня - тільки сотня.