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

 

 

Міністерство освіти і науки, молоді та спорту України

Інститут Підприємництва та Перспективних технологій при

Національному університеті “Львівська політехніка”

Кафедра інформаційних систем і технологій

 

Методичні вказівки

до лабораторної роботи № 1

“Операційні системи реального часу ”

з дисципліни

“Операційні системи”

 

для студентів базового напрямку підготовки по спеціальності

“Комп’ютерні науки” (шифр 0804)

 

 

                                 

 

 

Львів-2012

1. Вступ

 

Операційні системи реального часу (ОСРВ) призначені для забезпечення інтерфейсу до ресурсів критичних за часом систем реального часу. Основним завданням в таких системах є своєчасність (timeliness) виконання обробки даних.

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

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

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

Мартін Тіммерман сформулював наступні необхідні вимоги для ОСРВ [DEDSYS]:

· ОС повинна бути багатозадачного і допускає витіснення (preemptable),

· ОС повинна мати поняттям пріоритету для потоків,

· ОС повинна підтримувати передбачувані механізми синхронізації,

· ОС повинна забезпечувати механізм успадкування пріоритетів,

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

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

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

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

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

Як правило, більшість сучасних ОСРВ побудовано на основі мікроядра (kernel або nucleus), яке забезпечує планування і диспетчеризацію завдань, а також здійснює їх взаємодію. Незважаючи на зведення до мінімуму в ядрі ОС абстракцій, Мікроядро все ж таки повинно мати уявлення про абстракції процесу. Всі інші концептуальні абстракції операційних систем винесені за межі ядра, викликаються за запитом та виконуються як додатки.

Розглянемо концептуальні абстракції операційної системи через призму вимог до систем реального часу.

2. Процеси, потоки, завдання

 

Концепція багатозадачності (псевдопараллелізм) є суттєвою для системи реального часу з одним процесором, програми якої повинні бути здатні обробляти численні зовнішні події, що відбуваються практично одночасно. Концепція процесу, що прийшла з світу UNIX, погано реалізується в багатозадачному системі, оскільки процес має важкий контекст. Виникає поняття потоку (thread), який розуміється як підпроцесу, або легкий процес (light-weight process). Потоки існують в одному контексті процесу, тому перемикання між потоками відбувається дуже швидко, а питання безпеки не беруться до уваги. Потоки є легковажно, тому що їх регістровий контекст менше, тобто їхні управляючі блоки набагато компактнішим. Зменшуються накладні витрати, викликані збереженням та відновленням керуючих блоків перериваються потоків. Обсяг керуючих блоків залежить від конфігурації пам'яті. Якщо потоки виконуються в різних адресних просторах, система повинна підтримувати відображення пам'яті для кожного набору потоків.

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

 

3. Планування, пріоритети

 

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

У зв'язку з проблемами планування в ОСРВ вивчаються і розвиваються два підходи - статичні алгоритми планування (RMS - Rate Monotonic Scheduling) [LL73] і динамічні алгоритми планування (EDF - Earliest Deadline First).

RMS використовується для формального докази умов передбачуваності системи. Для реалізації цієї теорії необхідне планування на основі пріоритетів, переривають обслуговування (preemptive priority scheduling). У теорії RMS пріоритет заздалегідь призначається кожному процесу. Процеси повинні задовольняти таким умовам:

· процес має бути завершений за час його періоду,

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

Процеси виконуються відповідно до пріоритетів. При плануванні RMS перевага віддається завданням із самими короткими періодами виконання.

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

У всіх системах реального часу потрібно політика планування, керована дедлайну (deadline-driven scheduling). Однак цей підхід знаходиться у стадії розробки.

Зазвичай в ОСРВ використовується планування з пріоритетами, переривають обслуговування, яке засноване на RMS. Пріоритетне переривання обслуговування (preemption) є невід'ємною складовою ОСРВ, тому що в системі реального часу повинні існувати гарантії того, що подія з високим пріоритетом буде оброблено перед подією більш низького пріоритету. Все це веде до того, що ОСРВ потребує не тільки в механізмі планування на основі пріоритетів, переривають обслуговування, але також і у відповідному механізмі управління переривань. Більш того, ОСРВ повинна бути здатна забороняти переривання, коли необхідно виконати критичний код, який не можна переривати. Тривалість обробки переривань повинна бути зведена до мінімуму.

ОСРВ повинна володіти розвиненою системою пріоритетів. По-перше, це потрібно тому, що система сама може розглядатися як набір серверних додатків, що підрозділяються на потоки, і кілька високих рівнів пріоритетів має бути виділено системним процесам і потокам. По-друге, в складних додатках необхідно всі потоки реального часу поміщати на різні пріоритетні рівні, а потоки не реального часу розміщувати на один рівень (нижче, ніж будь-які потоки реального часу). При цьому потоки не реального часу можна обробляти в режимі циклічного планування (RRS - round-robin scheduling), при якому кожному процесу надається квант часу процесора, а коли квант закінчується, контекст процесу зберігається, і він ставиться в кінець черги. У багатьох ОСРВ для планування завдань на одному рівні використовується RRS. Пріоритетний рівень 0 зазвичай використовується для холостого режиму.

При плануванні на основі пріоритетів необхідно вирішити дві обов'язкові проблеми:

 

забезпечити виконання процесу з найвищим пріоритетом,

не допустити інверсії пріоритетів, коли завдання з високими пріоритетами очікують ресурси, захоплені завданнями з більш низькими пріоритетами.

Для боротьби з інверсією пріоритетів у ОСРВ часто використовується механізм успадкування пріоритетів, однак при цьому доводиться відмовлятися від планування на основі RMS, оскільки пріоритети стають динамічними.

4. Пам'ять

 

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

· Модель без захисту - системне і користувацьким простору не захищені один від одного, використовується два сегменти пам'яті: для коду та для даних; при цьому від системи не потрібно ніякого управління пам'яттю, не потрібно MMU (memory management unit - спеціальне апаратний пристрій для підтримки управління віртуальною пам'яттю).

· Модель захисту система / користувач - системне адресний простір захищене від адресного простору користувача, системні і користувальницькі процеси виконуються в загальному віртуальному адресному просторі, при цьому потрібно MMU. Захист забезпечується сторінковим механізмом захисту. Розрізняються системні і користувальницькі сторінки. Користувальницькі програми ніяк не захищені один від одного. Процесор знаходиться в режимі супервізора, якщо поточний сегмент має рівень 0, 1 або 2. Якщо рівень сегмента - 3, то процесор знаходиться в режимі користувача. У цій моделі необхідні чотири сегменти - два сегменти на рівні 0 (для коду та даних) і два сегменти на рівні 3. Механізм сторінкової захисту не додає накладних витрат, тому що захист перевіряється одночасно з перетворенням адреси, яке виконує MMU; при цьому операційна система не потребує в управлінні пам'яттю.

· Модель захисту користувач / користувач - до моделі система / користувач додається захист між користувацькими процесами; потрібно MMU. Як і в попередній моделі, використовується механізм сторінкової захисту. Усі сторінки позначаються як привілейовані, за винятком сторінок поточного процесу, які позначаються як користувацькі. Таким чином, виконують потік не може звернутися за межі свого адресного простору. ОС відповідає за оновлення прапора привілейованості для конкретної сторінки в таблиці сторінок при перемиканні процесу. Як і в попередній моделі використовуються чотири сегменти.

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

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

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

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

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

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

5. Переривання

При описі управління переривань зазвичай розрізняють дві процедури, а саме:

програма обробки переривання (ISR - interrupt servicing routine) - програма низького рівня в ядрі з обмеженими системними викликами, потік обробки переривання (IST - interrupt servicing thread) - потік рівня програми, який управляє перериванням, з доступом до всіх системним викликам.

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

6. Годинники і таймери

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

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

Більшість ОСРВ оперують відносним часом. Щось відбувається "до" і "після" деякого іншої події. У системі, повністю керованої подіями, необхідний часовий механізм (ticker), тому що там немає квантування часу (time slicing). Однак, якщо потрібні тимчасові мітки для деяких подій або необхідний системний виклик типу "чекати одну секунду", то потрібний тактовий генератор і / або таймер.

Синхронізація в ОСРВ здійснюється за допомогою механізму блокування (або очікування) до настання деякого події. Абсолютна час не використовується.

Реалізації в ОСРВ інших концептуальних абстракцій подібні їх реалізація в традиційних ОС.

7. Стандарти ОСРВ

 

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

Найбільш раннім і поширеним стандартом ОСРВ є стандарт POSIX (IEEE Portable Operating System Interface for Computer Environments, IEEE 1003.1). Початковий варіант стандарту POSIX з'явився в 1990 р. і був призначений для UNIX-систем, перші версії яких з'явилися в 70-х роках минулого століття. Специфікації POSIX визначають стандартний механізм взаємодії прикладної програми і операційної системи і в даний час включають набір більш ніж з 30 стандартів. Для ОСРВ найбільш важливі сім з них (1003.1a, 1003.1b, 1003.1c, 1003.1d, 1003.1j, 1003.21, 1003.2h), але широку підтримку в комерційних ОС отримали тільки три перших.

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

Деякі найбільш успішні компанії в області систем реального часу оголошують про своє рішення прийняти в якості стандарту специфікації одній зі своїх просунутих ОСРВ. Так вчинила компанія TRON (the RTOS Nucleus), яка в 1987р. випустила в світ перші ITRON специфікації - ITRON1. Далі в 1989р. вона розробила і випустила специфікації μITRON для 8 - і 16 - бітових мікроконтролерів, а також специфікації ITRON2 для 32-бітових процесорів. ОСРВ ITRON описується нижче у відповідному розділі. Цей стандарт є дуже поширеним в Японії.

Військова і аерокосмічна галузі висувають жорсткі вимоги до обчислювальних засобів, що впливає на ступінь безпеки цільової системи. В даний час є такі стандарти для ОСРВ в авіації - стандарт DO-178B і стандарт ARINC-653. Оскільки ці стандарти розроблені в США, варто відзначити ще європейський стандарт ED-12B, який є аналогом DO-178B.

Поширеним також є стандарт OSEK / VDX [OSEK], який спочатку розвивався для систем автомобільної індустрії.

POSIX

Стандарт POSIX був створений як стандартний інтерфейс сервісів операційних систем. Цей стандарт дає можливість створювати Переносимі програми. Згодом цей стандарт був розширений особливостями режиму реального часу [POSIX].

Специфікації POSIX задають стандартний механізм взаємодії програми і ОС. Необхідно відзначити, що стандарт POSIX тісно пов'язаний з ОС Unix; тим не менш, розробники багатьох ОСРВ намагаються витримати відповідність цьому стандарту. Відповідність стандарту POSIX для ОС і апаратної платформи повинне бути сертифіковане за допомогою прогону на них тестових наборів [POSIXTestSuite]. Однак, якщо ОС не є Unix-подібної, витримати це вимога стає непростим завданням. Тестові набори існують тільки для POSIX 1003.1a. Оскільки структура POSIX є сукупністю необов'язкових можливостей, постачальники ОС можуть реалізувати лише частина стандартного інтерфейсу, і при цьому говорити про POSIX-компліантності своєї системи.

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

До теперішнього часу стандарт POSIX розглядається як сімейство споріднених стандартів: IEEE Std 1003.n (де n - це номер).

Стандарт 1003.1a (OS Definition) містить базові інтерфейси ОС - підтримку єдиного процесу, підтримку багатьох процесів, управління завданнями, сигналами, групами користувачів, файловою системою, файловими атрибутами, управління файловими пристроями, блокуваннями файлів, пристроями вводу / виводу, пристроями спеціального призначення, системними базами даних, каналами, чергами FIFO, а також підтримку мови C.

Стандарт 1003.1b (Realtime Extensions) містить розширення реального часу - сигнали реального часу, планування виконання (з урахуванням пріоритетів, циклічне планування), таймери, синхронний і асинхронний ввід / вивід, ввід / вивід з пріоритетами, синхронізація файлів, блокування пам'яті, колективна пам'ять, передача повідомлень, семафори. Щоб стати POSIX-компліантной, ОС повинна реалізувати не менше 32 рівнів пріоритетів. POSIX визначає три політики планування обробки процесів:

· SCHED_FIFO - процеси обробляються в режимі FIFO і виконуються до завершення,

· SCHED_RR - round robin - кожному процесу виділяється квант часу,

· SCHED_OTHER - довільна реалізаційно-залежна політика, яка не переносяться на інші платформи.

Стандарт 1003.1c (Threads) стосується функцій підтримки багатопотокового обробки всередині процесу - управління потоками, планування з урахуванням пріоритетів, мьютекс (спеціальні синхронізуючі об'єкти в взаємодії між процесами, що подають сигнал, коли вони не захоплені яких-небудь потоком), пріоритетне спадкування у мьютекса, змінні стану (condition variables).

Стандарт 1003.1d включає підтримку додаткових розширень реального часу - семантика породження нових процесів (spawn), спорадичні серверне планування, моніторинг процесів і потоків часу виконання, таймаут функцій блокування, управління пристроями і переривань.

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

Стандарт 1003.2h стосується сервісів, що відповідають за працездатність системи.

DO-178BСтандарт DO-178B, створено радіотехнічний комісією з аеронавтики (RTCA, Radio Technical Commission for Aeronautics) для розробки ПЗ бортових авіаційних систем [DO178B]. Перша його версія була прийнята в 1982 р., друга (DO-178A) - в 1985-м, поточна DO-178B - в 1992 р. Готується прийняття нової версії, DO-178C. Стандартом передбачено п'ять рівнів серйозності відмови, і для кожного з них визначено набір вимог до програмного забезпечення, які повинні гарантувати працездатність всієї системи в цілому при виникненні відмов даного рівня серйозності

Даний стандарт визначає такі рівні сертифікації:

· А (катастрофічний),

· В (небезпечний),

· С (істотний),

· D (несуттєвий)

· Е (що не впливає).

ARINC-653

Стандарт ARINC-653 (Avionics Application Software Standard Interface) розроблений компанією ARINC в 1997 р. Цей стандарт визначає універсальний програмний інтерфейс APEX (Application / Executive) між ОС авіаційного комп'ютера і прикладним ПЗ. Вимоги до інтерфейсу між прикладним ПЗ і сервісами операційної системи визначаються таким чином, щоб дозволити прикладного ПЗ контролювати диспетчеризацію, зв'язок і стан внутрішніх оброблюваних елементів. У 2003 р. прийнята нова редакція цього стандарту. ARINC-653 в якості одного з основних вимог для ОСРВ в авіації вводить архітектуру ізольованих (partitioning) віртуальних машин.

OSEKСтандарт OSEK / VDX є комбінацією стандартів, які спочатку розроблялися в двох окремих консорціумах, згодом злилися. OSEK бере свою назву від німецького акроніми консорціуму, до складу якого входили провідні німецькі виробники автомобілів - BMW, Bosch, Daimler Benz (тепер Daimler Chrysler), Opel, Siemens і Volkswagen, а також університет в Карлсруе (Німеччина). Проект VDX (Vehicle Distributed eXecutive) розвивався спільними зусиллями французьких компаній PSA і Renault. Команди OSEK і VDX злилися в 1994р.

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

Стандарт OSEK / VDX складається з трьох частин - стандарт для операційної системи (OS), комунікаційний стандарт (COM) і стандарт для мережевого менеджера (NM). На додаток до цих стандартів визначається якийсь реалізаційний мова (OIL). Першим компонентом стандарту OSEK є стандарт для ОС, тому часто стандарт OSEK помилково сприймається як стандарт ОСРВ. Хоча ОС і є велика порція даного стандарту, потужність його полягає в інтеграції всіх його компонент.

У даній роботі розглядається тільки стандарт для операційної системи, і його опис наводиться в розділі 2.7.

Стандарти безпеки

У зв'язку до стандартів для ОСРВ варто відзначити широко відомий стандарт критеріїв оцінки придатності комп'ютерних систем (Trusted Computer System Evaluation Criteria - TCSEC) [DoD85]. Цей стандарт розроблений Міністерством оборони США і відомий також під назвою "Помаранчева книга" (Orange Book - через колір обкладинки).

У ряді інших країн були розроблені аналогічні критерії, на основі яких був створений міжнародний стандарт "Загальні критерії оцінки безпеки інформаційних технологій" (далі просто - Загальні критерії) (Common Criteria for IT Security Evaluation, ISO / IEC 15408) [CC99].

В "Помаранчевої книзі" перераховані сім рівнів захисту:

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

· В3 - домени безпеки. Цей рівень призначений для захисту систем від досвідчених програмістів.

· В2 - структурована захист. У систему з цим рівнем захисту не можна допустити проникнення хакерів.

· В1 - мандатний контроль доступу. Захист цього рівня, можливо, вдасться подолати досвідченому хакеру, але ніяк не рядовим користувачам.

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

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

· D - мінімальна захист. Цей нижній рівень захисту залишений для систем, які проходили тестування, але не змогли задовольнити вимогам більш високого класу. Що стосується Загальних критеріїв, то в них введено схожі вимоги забезпечення безпеки у вигляді оціночних рівнів (Evaluation Assurance Levels - EAL). Їх також сім:

· EAL7 - найвищий рівень припускає формальну верифікацію моделі об'єкта оцінки. Він застосовний до систем дуже високого ризику.

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

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

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

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

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

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

 

 

Відповідно до вимог Загальних критеріїв, продукти певного класу (наприклад, операційні системи) оцінюються на відповідність ряду функціональних критеріїв і критеріїв довіри - профілів захисту. Існують різні визначення профілів захисту щодо операційних систем, брандмауерів, смарт-карт і інших продуктів, які повинні відповідати певним вимогам у сфері безпеки. Наприклад, профіль захисту систем з розмежуванням доступу (Controlled Access Protection Profile) діє відносно операційних систем і покликаний замінити старий рівень захисту С2, визначається відповідно доамериканським стандартом TCSEC. Згідно з оціннимирівнями довіри сертифікація на відповідність більш високому рівню означає більш високу ступінь впевненості в тому, що система захисту продукту працює правильно і ефективно, і, згідно з умовами Загальних критеріїв, рівні 5-7 розраховані на тестування продуктів, створених із застосуванням спеціалізованих технологій безпеки.

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

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

 

 

Останнім часом однією з головних тем дослідницьких робіт в області операційних систем стало дослідження настроюваність (customizability) або адаптованості операційної системи. Настроюваної або адаптується операційною системою називається операційна система, що допускає гнучку модифікацію основних механізмів, стратегій і політик системи. Залежно від контексту, налаштовуваність системи може переслідувати різні цілі. В операційних системах загального призначення, як правило, такою метою є продуктивність системи в цілому. Для вбудованих систем настроюваність служить цілям енергозбереження та / або скорочення обсягу програмного забезпечення. Детальний систематичний огляд дослідних операційних систем з точки зору їх настроюваність дається в роботі Дениса та ін [DPM02].

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