Навигация
Прозоре обслуговування системних викликів
46640
знаков
1
таблица
6
изображений
2. Прозоре обслуговування системних викликів
Механізм системних викликів в процесорах сімейства x86 може бути реалізований різними способами. Історично для цього використовувалися програмні переривання (інструкція INTn), зокрема, в ОС Linux для виконання системного виклику використовується вектор 128. Повернення з системного виклику проводився за допомогою інструкції IRET. При виконанні інструкцій INTn і IRET процесор проводить ряд перевірок контексту виконання інструкції і його параметрів. Часте виконання процесом системних викликів може справити значний вплив на продуктивність системи. Як рішення, виробники процесорів запропонували додаткову пару інструкцій, спеціально призначених для швидкого переходу в режим ядра на задану адресу і назад: SYENTER / SYSEXIT від Intel і SYSCALL / SYSRET від AMD. Використання цих інструкцій є переважним, однак оригінальний механізм виконання системних викликів на базі програмних переривань, як і раніше підтримується з міркувань зворотної сумісності додатків.
У розглянутій у цій роботі системі віддаленого обслуговування системних викликів потрібно, щоб довірені програми використовували для виконання системних викликів механізм програмних переривань. Це зумовлено можливістю перехоплення інструкції програмного переривання і повернення з переривання безпосередньо за допомогою апаратури віртуалізації. Решта процеси в обчислювальній ВМ можуть використовувати довільні механізми системних викликів. З міркувань підвищення продуктивності перехоплення програмного переривання (інструкція INTn) встановлюється, тільки коли управління передається довіреній процесу, що дозволяє запобігти виходу з ВМ, якщо ця інструкція виконувалася будь-яким іншим (недоверенним) процесом.
Прапор перехоплення інструкції IRET, у свою чергу, встановлюється при кожному поверненні управління ВМ, якщо в системі виконується хоча б один довірений процес. Лише перехоплюючи всі такі інструкції, гіпервізор може відстежити момент, коли ОС передає управління довіреній процесу. Це необхідно для коректного відновлення процесу після отримання результатів з сервісної ВМ. Якщо результати готові, і повернення управління відбувається на наступну інструкцію після запиту на системний виклик, то гіпервізор записує результати, отримані з сервісної ВМ, на регістри і в пам'ять процесу, і процес продовжує виконання.
При перехопленні програмного переривання гіпервізор перевіряє, що воно було виконане з контексту довіреної процесу, і що вектор переривання відповідає вектору запитів на обслуговування системних викликів (128 в ОС Linux). Далі гіпервізор перевіряє, чи потрібне обслуговувати даний системний виклик віддалено в сервісній ВМ або локально в обчислювальній ВМ. Правила такого аналізу системних викликів будуть розглянуті в наступному розділі. Якщо виклик локальний, то гіпервізор просто відновлює управління ВМ, передаючи управління ядру ОС. Якщо виклик віддалений, то гіпервізор копіює параметри системного виклику з регістрів і, можливо, з адресного простору процесу у власну область пам'яті, формує запит і відправляє його в сервісну ВМ. Схема механізму прозорого обслуговування системних викликів наведена на рисунку 4.
Рисунок 4. Прозоре обслуговування системного виклику в обчислювальній ВМ
Для визначення адреси параметрів системного виклику у фізичній пам'яті гіпервізор програмним чином обходить таблиці приписки процесу і обчислює умовно фізичну адресу в контексті ВМ. Далі, знаючи відображення пам'яті ВМ на машинну пам'ять, гіпервізор обчислює точне розміщення параметрів виклику у фізичній пам'яті. В процесі читання параметрів, розташованих у пам'яті процесу (наприклад, у разі системного виклику write), можлива ситуація, коли дані розташовані в сторінки пам'яті, відкачати ОС на зовнішній пристрій.
Гіпервізор, виявивши відкачаний сторінку, вкидає у ВМ виключення «помилка сторінки» з адресою, відповідним відсутньої сторінці, і поновлює управління ВМ. ОС підкачує сторінку в пам'ять і повертає керування процесу за адресою інструкції виконання системного виклику. Процес повторно виконує системний виклик, і гіпервізор заново починає копіювання параметрів. Такий процес буде повторюватися до тих пір, поки всі сторінки пам'яті, зайняті вхідними параметрами системного виклику, не опиняться в фізичної пам'яті.
Після копіювання вхідних параметрів системного виклику гіпервізор відновлює виконання обчислювальної ВМ і переводить процес в стан очікування. Для цього в точці виконання системного виклику він вкидає синхронне переривання, для якого модуль ядра в обчислювальній ВМ зареєстрував обробник. В результаті, замість переривання 128, відповідного системним викликам, апаратура доставляє інше переривання.
Отримавши управління, обробник здійснює доступ до закритого семафор, що переводить процес в стан очікування штатними засобами ОС. Процес чекає відкриття семафора в режимі, допускають обробку зовнішніх подій. У разі надходження сигналу для процесу ОС перериває очікування семафора. Модуль ядра при цьому імітує запит на виконання неіснуючого системного виклику (наприклад, з номером 9999). Ядро ОС, зрозуміло, не буде виконувати цей запит, однак до того, як повернути управління процесу, він виконає обробку надійшли сигналів.
Після обслуговування сигналу ОС повертає управління процесу на вихідну інструкцію системного виклику, і процес повторно виконує запит на системний виклик. Гіпервізор перехоплює його, визначає, що в даний час системний виклик знаходиться в процесі віддаленого обслуговування, знову підміняє переривання, і процес вдруге переходить в стан очікування. Такий циклічний процес буде повторюватися до тих пір, поки з сервісної ВМ не надійдуть результати виконання системного виклику.
При отриманні результатів з сервісної ВМ гіпервізор необхідно відновити виконання довіреної процесу з наступною інструкції, причому в регістр r / eax повинен бути записаний результат виконання виклику, а в пам'ять процесу (наприклад, у разі системного виклику read) за заданими адресами повинні бути записані вихідні дані, якщо вони є.
Гіпервізор виводить процес зі стану очікування за допомогою вкидання іншого синхронного переривання в обчислювальну ВМ, обробник якого звільняли семафор і, тим самим, відновлює виконання процесу. Процес далі виконує гіпервизов на запит результатів системного виклику. Зауважимо, що хоча гіпервизов проводиться з контексту ядра, в точці гіпервизова на апаратурі завантажені власні таблиці приписки довіреної процесу. Гіпервізор переглядає таблиці і перевіряє, що віртуальні адреси, за якими мають бути записані результати, відображені на фізичну пам'ять, і доступ до цих адресами відкрито по запису. Наявність доступу тільки з читання може означати, що дана область пам'яті є «копійований при операції запису». При наявності доступу по запису до всього необхідного діапазону адрес гіпервізор копіює результати виконання системного виклику зі сховища в адресний простір процесу і відновлює виконання ВМ. В іншому випадку гіпервізор для всіх необхідних віртуальних сторінок вкидає у ВМ виключення «помилка сторінки», що дає ОС вказівку виділити пам'ять для відповідної віртуальної сторінки і відобразити її на фізичну пам'ять.
При віддаленому обслуговуванні системного виклику делегат може отримати сигнал від ОС в сервісній ВМ, наприклад, сигнал SIGPIPE про розрив мережевого з'єднання. У цьому випадку делегат сповіщає гіпервізор про здобутий сигналі, і гіпервізор доставляє сигнал довіреній процесу. Для цього він інформує про сигнал модуль ядра ОС, який, у свою чергу, доставляє сигнал процесу засобами API ядра ОС Linux. Доставка процесу сигналу може привести до його аварійного завершення. У цьому випадку монітор повідомить гіпервізор про закінчення виконання процесу, і гіпервізор звільнить пам'ять, відведену під службові структури даних.
Похожие работы
... WRR) і його модифікації; - кругове обслуговування з дефіцитом (Deficit Round-Robin, DRR) і його модифікації. Рисунок 1 – Класифікація механізмів обслуговування черг 2. Механізм обслуговування черг FIFO обслуговування алгоритм черга комутатор FIFO (First In – First Out, "першим прийшов – першим пішов") є найпростішим механізмом обслуговування черг, відповідно до якого пакети передаються ...
... допомогою програм пакету ResourseKit фірми Microsoft. Увага! Будь-яке некваліфіковане втручання в структуру системного реєстру може призвести до краху всієї системи. Якщо ви адмініструєте сервер, чи робочу станцію на основі Win9x/nt/2000 , то системний реєстр допоможе вам підвищити рівень безпеки та ефективності вашої системи . Однак, кожен раз запускати редактор реєстру і шукати потрібні ключі , ...
... RTOS складається з ядра, планувальника процесів (process manager) і розширених сервісів на рівні користувача. Як справжня мікроядерного операційна система, QNX Neutrino RTOS реалізує в ядрі ОС тільки найбільш фундаментальні сервіси, такі як передача повідомлень, сигнали, таймери, планування потоків, об'єкти синхронізації. Всі інші сервіси ОС, драйвери та програми виконуються як окремі процеси, які ...
... своєчасне виявлення відхилень від прийнятих стандартів і цілей кредитної політики банку. Кредитний моніторинг є одним із важливих елементів удосконалення механізму здійснення кредитних операцій. Контроль за ходом погашення позички і виплатою відсотків по ній служить важливим етапом усього процесу кредитування. Він полягає в періодичному аналізі кредитного досьє позичальника, перегляді кредитного ...
0 комментариев