Захист адресного простору задач.

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

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

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

Рівні привілеїв для захисту адресного простору задач.

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

У мікропроцесорахi80x86 маються недва, а чотири рівні привілеїв. Часто рівні привілеїв називають кільцями захисту, оскільки це іноді допомагає пояснити принцип дії самого механізму; тому говорять, що деякий програмний модуль «виконується в кільці захисту з таким-то номером». Для вказівки рівня привілеїв використовуються два біти, тому код 00 позначає самий вищий рівень, а код 11 (=3) — самий нижчий. Найвищий рівень привілеїв призначений для операційної системи (насамперед, для ядра ОС), найнижчий — для прикладних задач користувача. Проміжні рівні привілеїв введені для більшої свободи системних програмістів в організації надійних обчислень при створенні ОС і іншого системного ПЗ. Передбачалося, що рівень з номером (кодом) 1 може бути використаний, наприклад, для системного сервісу — програм обслуговування апаратури, драйверів, що працюють з портами введення/виведення. Рівень привілеїв з кодом 2 може бути використаний для створення користувацьких інтерфейсів, систем керування базами даних і т.п., тобто для реалізації спеціальних системних функцій, що стосовно супервізора ОС поводяться як звичайні додатки. Так, наприклад, система OS/2 використовує три рівні привілеїв: з нульовим рівнем привілеїв виконується код самої ОС, на другому рівні виповнюються системні процедури підсистеми введення/виведення, на третьому рівні виповнюються прикладні задачі користувачів. Однак найчастіше на практиці використовуються тільки два рівні — нульової і третій. Таким чином, згаданий режим супервізора для мікропроцесорів і80x86 відповідає виконанню коду з рівнем привілеїв 0 (його позначають так: PL0 – privilege level). Підводячи підсумок, можна констатувати, що саме рівень привілеїв задач визначає, які команди в них можна використовувати і яка підмножина сегментів і/чи сторінок у їхньому адресному просторі вони можуть обробляти.

Основними системними об'єктами, якими маніпулює процесор при роботі в захищеному режимі, є дескриптори. Дескриптори сегментів містять інформацію про рівень привілею відповідного сегмента чи коду даних. Рівень привілею задачі, що виконується, визначається значенням поля привілею, що знаходиться в дескрипторі її поточного кодового сегмента. Нагадаємо, що в кожнім дескрипторі сегмента (див. мал.3.3) мається поле DPL у байті прав доступу, що і визначає рівень привілею зв'язаного з ним сегмента. Таким чином, поле DPL поточного сегмента коду стає полем CPL. При звертанні до якого-небудь сегмента і відповідному селекторі вказується запитуваний рівень привілеїв RPL (див. мал. 3.4).

У межах однієї задачі використовуються сегменти зрізним рівнем привілею й у визначені моменти часу виконуються чи обробляються сегменти з відповідними їм рівнями привілею. Механізм перевірки привілеїв працює в ситуаціях, які можна назвати міжсегментними переходами (звертаннями). Це доступ до сегмента даних чи стековому сегменту, міжсегментні передачі керування у випадку переривань (і особливих ситуацій), при використанні команд CALL, JMP, INT, IRET, RET. У таких міжсегментних звертаннях беруть участь два сегменти: цільовий сегмент (до якого ми звертаємося) і поточний сегмент коду, з якого йде звертання.

Процесор порівнює згадані значення CPL, RPL, DPL і на основі поняття ефективного рівня привілеїв(EPL = max (RPL, DPL)) обмежує можливості доступу до сегментів за наступними правилами, у залежності від того, чи йде мова про звертання до коду чи до даних.

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

Якщо цільовий сегмент є сегментом стека, то правило перевірки має вид

CPL-DPL=RPL.

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

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

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

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

Мал. 7.9 Механізм шлюзів для переходу на другий рівень привілеїв.

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

Для одержання доступу до більш привілейованогокоду задача повинна звернутися до нього не безпосередньо (шляхом вказівки дескриптора цього коду), а звертанням до шлюзу цього сегмента (мал. 3.10).

У цьому дескрипторі замість адреси сегмента вказуються селектор, що дозволяє знайти дескриптор шуканого сегмента коду, і адреса (зсув призначення), з якого буде виконуватися підлеглий сегмент, тобто повна 32 бітна адреса. Форматдескриптора шлюзуприведений на мал. 3.11. Адресувати шлюз виклику можна за допомогою команди CALL. Власне кажучи, дескриптори шлюзів виклику не є дескрипторами (сегментів), але вони можуть бути розташовані серед звичайних дескрипторів у дескрипторних таблицях процесу. Зсув, що вказується в команді переходу на інший сегмент (FAR CALL), ігнорується, і фактично здійснюється перехід на команду, адресу якої визначається через зсув зі шлюзу виклику. Цим гарантується попадання тільки на дозволені крапки входу в підлеглі сегменти.

Мал. 7.10 Перехід на сегмент більш привілейованого коду.

Читайте також:

<== попередня сторінка	\|	наступна сторінка ==>
Мал. 7.4. Селектор сегменту.	\|	Файлова система HPFS.

Не знайшли потрібну інформацію? Скористайтесь пошуком google:

Генерація сторінки за: 0.014 сек.