47599 (572041), страница 2
Текст из файла (страница 2)
Рисунок 2. Паспорт довіреної завдання.
Монітор визначає, для яких процесів слід запитувати довірений режим виконання, ґрунтуючись на спеціальному файлі конфігурації – паспорті завдання (рис. 2). Паспорт містить ім'я спочатку завантажується програми (не обов'язково довіреної) і список переданих їй параметрів командного рядка. Основна частина паспорта складається з набору шаблонів для ідентифікації нових процесів, для яких слід запитувати включення довіреної режиму. Для кожного шаблона вказується унікальний ідентифікатор довіреної програми, зареєстрованої в гіпервізора. У гіпервізора для кожної зареєстрованої програми перерахований набір хеш-кодів, що дозволяють перевірити, що запускається програма дійсно є однією з довірених [1].
При виконанні дочірнім процесом системного виклику exec монітор проводить пошук шаблону, який може бути зіставлений імені запускається програми, і, у разі успіху, робить запит гіпервізор на включення довіреної режиму, повідомляючи йому ідентифікатор процесу (PID) і ідентифікатор відповідної довіреної програми (наприклад, 444 на рис. 2). Гіпервізор перевіряє допустимість включення довіреної режиму для процесу в даній точці виконання і, в разі дотримання контекстних умов безпеки [1], активує довірений режим. При перехопленні системного виклику fork монітор активує довірений режим для дочірнього процесу лише в тому випадку, якщо батьківський процес виконується в довіреному режимі. Слід зазначити, що гіпервізор контролює коректність виконання запиту, тобто що батьківський процес виконується в довіреному режимі і дійсно виконав системний виклик fork.
Паспорт задачі також містить адресу довільній інструкції RET в коді довіреної програми. Монітор за допомогою модуля (розширення) ядра в обчислювальній ВМ реєструє для довіреної процесу за цією адресою обробник сигналу, не використовуваного процесом. Здійснення такого сигналу довіреній процесу призведе просто до виконання інструкції RET. Цей сигнал використовується для скасування виконання системного виклику в обчислювальній ВМ у тих випадках, коли для коректного обслуговування системного виклику його потрібно виконувати в обох віртуальних машинах (див. розділ 3.1).
1.1 Компоненти системи та їх взаємодія
Віддалене обслуговування системних викликів реалізується гіпервізор спільно з іншими компонентами системи, що функціонують в обох ВМ – обчислювальної і сервісною. Компоненти функціонує як у просторі користувача (монітор, диспетчер, делегати), так і в просторі ядра ОС (завантажувані модулі ядра ОС).
У ході ініціалізації системи в ядро ОС в обчислювальній та сервісної ВМ динамічно завантажуються модулі ядра. Кожен модуль виділяє безперервне простір фізичної пам'яті (за замовчуванням 1 сторінку розміром 4Кб) для організації кільцевого буфера, реєструє кілька обробників переривань, за допомогою яких гіпервізор сповіщає віртуальну машину про події, що вимагають обробки і повідомляє цю інформацію (адреса буфера та номери переривань) гіпервізор за допомогою гіпервизова. У сервісній ВМ також запускається користувальницький процес – диспетчер.
У ході віддаленого обслуговування системного виклику компоненти системи взаємодіють між собою, причому механізми взаємодії реалізовані по-різному (рис. 3). Реалізація механізму взаємодії деякої пари компонент визначається рівнями привілеїв, на яких вони виконуються. Будь-яка компонента може звернутися до гіпервізор допомогою гіпервизова. Виконання ВМ при цьому переривається, і управління передається гіпервізора. Синхронний характер цього звернення дозволяє передавати параметри гіпервизова аналогічно тому, як користувальницький процес передає параметри ядру ОС при виконанні системного виклику: числові параметри та адреси областей пам'яті передаються через регістри, при необхідності гіпервізор читає область пам'яті віртуальної машини за вказаними адресами і витягує з неї (або записує в неї) додаткову інформацію.
Користувальницький процес (диспетчер або монітор) звертається за сервісом до модуля ядра за допомогою системних викликів. Модуль ядра реєструє в ОС спеціальне логічний пристрій, видиме на рівні файлової системи як файл. Операції доступу до цього файлу (системні виклики read / write / ioctl) викликають відповідні функції в драйвері логічного пристрою. Драйвер обробляє запит процесу і повертає управління йому. Якщо операція блокуюча, то драйвер може призупинити виконання процесу до тих пір, поки він не зможе обслужити запит. Модуль ядра звертається до призначеного для користувача процесу за допомогою посилки сигналів.
Взаємодія користувальницьких процесів один з одним (наприклад, диспетчера з делегатами) здійснюється за допомогою стандартних механізмів взаємодії між процесами (IPC) ОС Linux – поділюваної пам'яті, черги повідомлень і пр. Всі делегати в сервісній ВМ є членами однієї ієрархії процесів, висхідній до диспетчера, що полегшує контроль створення поділюваних між процесами ресурсів: ресурс, який створюється з батьків, доступний нащадку, а ресурс, який створюється нащадком, не доступний батьку.
Найбільш складною є ситуація, в якій гіпервізор потрібно сповістити компоненти у віртуальній машині про деяке подію. Для цього гіпервізор використовує можливість, що надається апаратурою віртуалізації, вкидати переривання і виняткові ситуації у віртуальну машину за допомогою відповідних полів в керуючій структурі VMCB ВМ. Тоді після відновлення ВМ апаратура забезпечує їй доставку переривання безпосередньо перед виконанням першої інструкції в ВМ. У результаті вкидання переривання ОС передає управління на обробник (вектор) даного переривання, зареєстрований модулем ядра в таблиці обробників переривань в процесі ініціалізації системи.
Параметри події передаються через кільцевої буфер. Буфер фізично розташований в області пам'яті ВМ і розділяється між гіпервізор та ВМ за схемою «постачальник – споживач». Буфер являє собою замкнутий в кільце масив структур даних (фіксованого розміру), голова якого зрушується в міру виїмки запитів з буфера, а хвіст – в міру приміщення запитів в буфер. Якщо буфер переповнений, то доставка запиту відкладається до тих пір, поки в буфері не звільниться місце, тобто поки ОС не обробить хоча б одне з раніше згенерованих подій. Запити, які очікують доставки в ВМ, накопичуються в черзі в пам'яті гіпервізора.
Структура даних, що представляє собою елемент кільцевого буфера, єдина для всіх подій і включає поля для всіх можливих параметрів фіксованої довжини. Параметри змінної довжини передаються через окремий буфер змінного розміру, розташований в пам'яті гіпервізора – сховище. Координати параметра змінної довжини – зміщення від початку сховища і довжина – специфікується в структурі даних кільцевого буфера. Наприклад, для системного виклику write структура включає 3 поля: ідентифікатор файлового дескриптора, початок (зміщення) буфера в сховище і довжина буфера. Для кожного довіреної процесу гіпервізор підтримує окремий екземпляр сховища.
При отриманні запиту, що містить параметри змінної довжини, код за ВМ, якому призначається цей запит (наприклад, делегат), виконує гіпервизов на доступ до сховища, передаючи координати запитуваної параметра і адреса буфера у власній пам'яті, в який повинні бути записані дані зі сховища. Гіпервізор обслуговує запит і відновлює виконання ВМ. При цьому він контролює, що кордони запитуваної блоку даних не виходять за межі сховища. Доступ до сховища можливий як з читання, так і по запису.
При необхідності передати запит однієї з компонент всередині ВМ гіпервізор очікує, коли виконання ВМ буде перерване за тієї чи іншої події (наприклад, за таймером), і аналізує, чи може він послати запит в даній точці. Для цього в кільцевому буфері має бути вільне місце, а переривання не повинні бути маскуватися в ВМ. Якщо це так, то гіпервізор (при необхідності) заповнює сховище параметрами змінної довжини, формує структуру даних для кільцевого буфера, вказуючи в ній координати параметрів у сховище, записує сформований запит в буфер і вкидає переривання. Вкидання переривання передає управління оброблювачеві переривання, який аналізує вміст буфера і або обслуговує його самостійно, або передає запит другий компоненті, що відповідає за його обслуговування (наприклад, диспетчеру).
Якщо одержувачем запиту гіпервізора є користувальницький процес (наприклад, диспетчер), то доставка такого запиту здійснюється транзитом через драйвер логічного пристрою. Користувальницький процес звертається до файлу устрою і, у разі відсутності запиту на даний момент, переходить в стан очікування. Під час отримання запиту від гіпервізора обробник переривання сповіщає про це драйвер пристрою. Той, у свою чергу, читає запит з кільцевого буфера, копіює його в пам'ять процесу і виводить його зі стану очікування. Якщо запит містить параметри змінної довжини, то доступ до сховища здійснюється тим користувальницьким процесом, який безпосередньо обслуговує запит.
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) за заданими адресами повинні бути записані вихідні дані, якщо вони є.
Гіпервізор виводить процес зі стану очікування за допомогою вкидання іншого синхронного переривання в обчислювальну ВМ, обробник якого звільняли семафор і, тим самим, відновлює виконання процесу. Процес далі виконує гіпервизов на запит результатів системного виклику. Зауважимо, що хоча гіпервизов проводиться з контексту ядра, в точці гіпервизова на апаратурі завантажені власні таблиці приписки довіреної процесу. Гіпервізор переглядає таблиці і перевіряє, що віртуальні адреси, за якими мають бути записані результати, відображені на фізичну пам'ять, і доступ до цих адресами відкрито по запису. Наявність доступу тільки з читання може означати, що дана область пам'яті є «копійований при операції запису». При наявності доступу по запису до всього необхідного діапазону адрес гіпервізор копіює результати виконання системного виклику зі сховища в адресний простір процесу і відновлює виконання ВМ. В іншому випадку гіпервізор для всіх необхідних віртуальних сторінок вкидає у ВМ виключення «помилка сторінки», що дає ОС вказівку виділити пам'ять для відповідної віртуальної сторінки і відобразити її на фізичну пам'ять.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
