Навигация
1. Архітектура системи
Технологія віртуалізації дозволяє виконувати ОС в апаратній віртуальній машині (ВМ) під управлінням порівняно невеликий за розміром системної програми – монітора віртуальних машин (гіпервізора) [5]. Апаратна віртуальна машина є ефективний ізольований дублікат реальної машини, і виконання в ній операційної системи не вимагає внесення будь-яких змін в код ОС. Гіпервізор повністю контролює взаємодію ОС в ВМ з устаткуванням і може забезпечити надійну ізоляцію ВМ, спираючись на апаратні механізми захисту.
Функціонування гіпервізора та організація виконання віртуальної машини багато в чому схожі з тим, як операційна система керує виконанням користувацьких процесів. Гіпервізор ініціалізує системні структури даних, необхідні обладнанню, і виконує спеціальну інструкцію VMRUN, що реалізовує запуск ВМ і передачу управління відповідної інструкції коду ОС. При виникненні апаратного події (переривання) або при виконанні операційною системою привілейованої інструкції (у тому числі, системного виклику) виконання ВМ переривається, і управління передається гіпервізор на наступну інструкцію після VMRUN. Після обробки перехопленого події гіпервізор відновлює виконання ВМ.
Архітектура системи виглядає наступним чином. Гіпервізор реалізує одночасне виконання двох віртуальних машин (мал. 1), що працюють під управлінням операційної системи Linux однаковою. Відзначимо, що операційні системи у віртуальних машинах можуть бути різними, якщо гіпервізор при цьому забезпечує необхідне перетворення системних викликів між вихідної та цільової операційними системами. У обчислювальної ВМ виконуються процеси користувача, серед яких виділено набір довірених процесів. Гіпервізор надає довіреною процесам привілей доступу до ресурсів, що обслуговується ОС в сервісній ВМ (контрольованим ресурсів); інші процеси доступу до цих ресурсів не мають. Доступ довірених процесів до контрольованих ресурсів проводиться за допомогою перехоплення їх системних викликів і, при необхідності, їх перенаправлення для обслуговування в сервісну ВМ.
Обидві віртуальні машини виконуються асинхронно, і обчислювальна ВМ не блокується на час віддаленого обслуговування системного виклику. У цей час процес, який ініціював системний виклик, знаходиться в стані очікування, а всі інші процеси в обчислювальній ВМ продовжують виконуватися нормальним чином. Більш того, система допускає одночасне обслуговування декількох віддалених системних викликів, що надходять від різних довірених процесів.
При перехопленні запиту процесу на виконання системного виклику гіпервізор копіює всі вхідні параметри виклику у власну область пам'яті і передає запит на обслуговування виклику в сервісну ВМ. Системний виклик може бути блокуючим (наприклад, read), і час його виконання в загальному випадку не обмежена. Для уникнення блокування всієї обчислювальної ВМ на час обслуговування виклику процес, який ініціював системний виклик, переводиться в стан очікування, дозволяючи іншим процесам продовжити своє виконання. При надходженні з сервісної ВМ результатів обслуговування виклику гіпервізор перериває виконання обчислювальної ВМ, виводить процес зі стану очікування і копіює результати в його адресний простір. Перебування процесу в стані очікування реалізується штатними засобами ОС в ВМ без вмешівательства в роботу механізму управління процесами в операційній системі.
Всередині сервісної ВМ виконується набір процесів – делегатів, які є екземплярами спеціалізованої програми. Кожен із делегатів обслуговує запити на системні виклики окремого довіреної процесу з обчислювальної ВМ, причому ієрархія делегатів в сервісній ВМ відповідає ієрархії довірених процесів в обчислювальній ВМ. Новий делегат породжується кожного разу при створенні нового довіреної процесу і знищується при завершенні роботи цього процесу.
Виконання делегата полягає в циклічному виконанні системних викликів, що надійшли від відповідного довіреної процесу, і сповіщення гіпервізора про результати (делегат, на відміну від довіреної процесу, знає про існування гіпервізора). Делегати отримують запит на виконання системного виклику від спеціалізованого процесу – диспетчера – через механізм взаємодії між процесами (черга повідомлень). Всі запити, що надходять від гіпервізора, проходять через процес-диспетчер. Диспетчер відстежує відповідності між ідентифікаторами довірених процесів і ідентифікаторами делегатів і, отримавши запит від гіпервізора на обслуговування системного виклику деякого довіреної процесу, перенаправляє його відповідного делегату. Подальше обслуговування запиту цілком проводиться делегатом без участі диспетчера. Зокрема, делегат самостійно виконує доступ до сховища, сповіщає гіпервізор про результати системного виклику і т.д.
Ієрархія кожного довіреної процесу сходить до службового процесу, що є екземпляром спеціальної користувацької програми – монітора. Перший довірений процес завжди породжується монітором. Монітор, у свою чергу, не є надійною програмою. Завдання монітора складається у запуску нового (в тому числі, першого) довіреної процесу та відстеження його стану, а також стану всіх його дочірніх процесів, частина з яких можуть бути довіреними, а частина – ні.
Монітор реалізований на базі стандартного інтерфейсу налагодження ptrace. Монітор перехоплює події породження та завершення процесів, в тому числі, аварійного, наприклад, при отриманні сигналу процесом, для якого у нього не зареєстрований обробник. При виконанні одним з дочірніх процесів системного виклику fork або exec монітор визначає, чи треба даному процесу виконання у довіреному режимі (тобто чи буде новий процес довіреною), і, у разі необхідності, може вимагати гіпервізор про його включення для процесу. При завершенні довіреної процесу монітор також сповіщає про це гіпервізор.
Рисунок 2. Паспорт довіреної завдання.
Монітор визначає, для яких процесів слід запитувати довірений режим виконання, ґрунтуючись на спеціальному файлі конфігурації – паспорті завдання (рис. 2). Паспорт містить ім'я спочатку завантажується програми (не обов'язково довіреної) і список переданих їй параметрів командного рядка. Основна частина паспорта складається з набору шаблонів для ідентифікації нових процесів, для яких слід запитувати включення довіреної режиму. Для кожного шаблона вказується унікальний ідентифікатор довіреної програми, зареєстрованої в гіпервізора. У гіпервізора для кожної зареєстрованої програми перерахований набір хеш-кодів, що дозволяють перевірити, що запускається програма дійсно є однією з довірених [1].
При виконанні дочірнім процесом системного виклику exec монітор проводить пошук шаблону, який може бути зіставлений імені запускається програми, і, у разі успіху, робить запит гіпервізор на включення довіреної режиму, повідомляючи йому ідентифікатор процесу (PID) і ідентифікатор відповідної довіреної програми (наприклад, 444 на рис. 2). Гіпервізор перевіряє допустимість включення довіреної режиму для процесу в даній точці виконання і, в разі дотримання контекстних умов безпеки [1], активує довірений режим. При перехопленні системного виклику fork монітор активує довірений режим для дочірнього процесу лише в тому випадку, якщо батьківський процес виконується в довіреному режимі. Слід зазначити, що гіпервізор контролює коректність виконання запиту, тобто що батьківський процес виконується в довіреному режимі і дійсно виконав системний виклик fork.
Паспорт задачі також містить адресу довільній інструкції RET в коді довіреної програми. Монітор за допомогою модуля (розширення) ядра в обчислювальній ВМ реєструє для довіреної процесу за цією адресою обробник сигналу, не використовуваного процесом. Здійснення такого сигналу довіреній процесу призведе просто до виконання інструкції RET. Цей сигнал використовується для скасування виконання системного виклику в обчислювальній ВМ у тих випадках, коли для коректного обслуговування системного виклику його потрібно виконувати в обох віртуальних машинах (див. розділ 3.1).
Похожие работы
... 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 комментариев