Механізм обслуговування системних викликів
Контрольная работа - Компьютеры, программирование
Другие контрольные работы по предмету Компьютеры, программирование
реної процесу, і сповіщення гіпервізора про результати (делегат, на відміну від довіреної процесу, знає про існування гіпервізора). Делегати отримують запит на виконання системного виклику від спеціалізованого процесу диспетчера через механізм взаємодії між процесами (черга повідомлень). Всі запити, що надходять від гіпервізора, проходять через процес-диспетчер. Диспетчер відстежує відповідності між ідентифікаторами довірених процесів і ідентифікаторами делегатів і, отримавши запит від гіпервізора на обслуговування системного виклику деякого довіреної процесу, перенаправляє його відповідного делегату. Подальше обслуговування запиту цілком проводиться делегатом без участі диспетчера. Зокрема, делегат самостійно виконує доступ до сховища, сповіщає гіпервізор про результати системного виклику і т.д.
Ієрархія кожного довіреної процесу сходить до службового процесу, що є екземпляром спеціальної користувацької програми монітора. Перший довірений процес завжди породжується монітором. Монітор, у свою чергу, не є надійною програмою. Завдання монітора складається у запуску нового (в тому числі, першого) довіреної процесу та відстеження його стану, а також стану всіх його дочірніх процесів, частина з яких можуть бути довіреними, а частина ні.
Монітор реалізований на базі стандартного інтерфейсу налагодження ptrace. Монітор перехоплює події породження та завершення процесів, в тому числі, аварійного, наприклад, при отриманні сигналу процесом, для якого у нього не зареєстрований обробник. При виконанні одним з дочірніх процесів системного виклику fork або exec монітор визначає, чи треба даному процесу виконання у довіреному режимі (тобто чи буде новий процес довіреною), і, у разі необхідності, може вимагати гіпервізор про його включення для процесу. При завершенні довіреної процесу монітор також сповіщає про це гіпервізор.
Рисунок 2. Паспорт довіреної завдання.
Монітор визначає, для яких процесів слід запитувати довірений режим виконання, ґрунтуючись на спеціальному файлі конфігурації паспорті завдання (рис.2). Паспорт містить імя спочатку завантажується програми (не обовязково довіреної) і список переданих їй параметрів командного рядка. Основна частина паспорта складається з набору шаблонів для ідентифікації нових процесів, для яких слід запитувати включення довіреної режиму. Для кожного шаблона вказується унікальний ідентифікатор довіреної програми, зареєстрованої в гіпервізора. У гіпервізора для кожної зареєстрованої програми перерахований набір хеш-кодів, що дозволяють перевірити, що запускається програма дійсно є однією з довірених [1].
При виконанні дочірнім процесом системного виклику exec монітор проводить пошук шаблону, який може бути зіставлений імені запускається програми, і, у разі успіху, робить запит гіпервізор на включення довіреної режиму, повідомляючи йому ідентифікатор процесу (PID) і ідентифікатор відповідної довіреної програми (наприклад, 444 на рис.2). Гіпервізор перевіряє допустимість включення довіреної режиму для процесу в даній точці виконання і, в разі дотримання контекстних умов безпеки [1], активує довірений режим. При перехопленні системного виклику fork монітор активує довірений режим для дочірнього процесу лише в тому випадку, якщо батьківський процес виконується в довіреному режимі. Слід зазначити, що гіпервізор контролює коректність виконання запиту, тобто що батьківський процес виконується в довіреному режимі і дійсно виконав системний виклик fork.
Паспорт задачі також містить адресу довільній інструкції RET в коді довіреної програми. Монітор за допомогою модуля (розширення) ядра в обчислювальній ВМ реєструє для довіреної процесу за цією адресою обробник сигналу, не використовуваного процесом. Здійснення такого сигналу довіреній процесу призведе просто до виконання інструкції RET. Цей сигнал використовується для скасування виконання системного виклику в обчислювальній ВМ у тих випадках, коли для коректного обслуговування системного виклику його потрібно виконувати в обох віртуальних машинах (див. розділ 3.1).
1.1 Компоненти системи та їх взаємодія
Віддалене обслуговування системних викликів реалізується гіпервізор спільно з іншими компонентами системи, що функціонують в обох ВМ обчислювальної і сервісною. Компоненти функціонує як у просторі користувача (монітор, диспетчер, делегати), так і в просторі ядра ОС (завантажувані модулі ядра ОС).
У ході ініціалізації системи в ядро ОС в обчислювальній та сервісної ВМ динамічно завантажуються модулі ядра. Кожен модуль виділяє безперервне простір фізичної памяті (за замовчуванням 1 сторінку розміром 4Кб) для організації кільцевого буфера, реєструє кілька обробників переривань, за допомогою яких гіпервізор сповіщає віртуальну машину про події, що вимагають обробки і повідомляє цю інформацію (адреса буфера та номери переривань) гіпервізор за допомогою гіпервизова. У сервісній ВМ також запускається користувальницький процес диспетчер.
У ході віддаленого обслуговування системного виклику компоненти системи взаємодіють між собою, причому механізми взаємодії реалізовані по-різному (рис.3). Реалізація механізму взаємодії деякої пари компонент визначається рівнями привілеїв, на яких вони виконуються. Будь-яка компонента може звернутися до гіпервізор допомогою гіпервизова. Виконання ВМ при цьому переривається, і управління передається гіпервізора. Синхронний характер цього звернення дозволяє пер?/p>