Введення
Рішеннядеяких задач комп'ютерної безпеки засноване на обмеженні доступу програмногокоду до різного роду ресурсів, зокрема, мережевих ресурсів і файлової системи.Надавши доступ до цих ресурсів лише окремим довіреною програмами, можнагарантувати (при додатковому контролі цілісності цих програм) виконанняважливих вимог з безпеки, серед яких слід зазначити запобігання витоку критичноважливої інформації через різні канали передачі даних: мережеве з'єднання,переносні (USB) накопичувачі та ін.
Сучасніопераційні системи (ОС) надають широкі можливості з управління доступомпроцесів до ресурсів комп'ютера. Однак недостатня надійність масових ОС (такихяк Windows, Linux та ін.) [1] робить актуальним завдання розробки незалежнихвід ОС (ортогональних до неї) програмних засобів захисту інформації. Такізасоби захисту можуть бути реалізовані з використанням технології апаратної віртуалізації,коли захищається система виконується в апаратній віртуальній машині (ВМ), асистема захисту розміщується в тілі монітора віртуальних машин (також званогогіпервізор) [2,4]. Функціонування гіпервізора на більш високому апаратномурівні привілеїв дозволяє повністю контролювати виконання як коду ОС, так іпризначених для користувача програм, залишаючись при цьому апаратно захищенимвід шкідливого впливу з боку коду в ВМ, у тому числі, коду, що виконується впривілейованому режимі.
Користувальницькийпроцес в сучасних ОС не має прямого доступу до апаратних ресурсів; операційнасистема являє процесу деяку абстрактну модель апаратного забезпечення,взаємодія з якою здійснюється за допомогою набору операцій – системних викликів(СВ). Зокрема, для встановлення мережевого з'єднання з віддаленим комп'ютером іпередачі йому даних процесу необхідно виконати в заданому порядку кілька цілкомпевних системних викликів (socket, connect, send і т. п.).
Унаших роботах [2,3] було показано, як за допомогою поділу повноважень зобслуговування ресурсів між віртуальними машинами і делегування обслуговуваннясистемних викликів від однієї віртуальної машини іншої можуть бути вирішенідеякі задачі комп'ютерної безпеки. Запропоновані рішення в цілому базуються насхемі, зображеній на рисунку 1. Гіпервізор забезпечує одночасне виконання двохізольованих один від одного віртуальних машин. Обидві ВМ працюють підуправлінням однієї і тієї ж операційної системи. Перша ВМ – обчислювальна – єосновною. Користувач може працювати з нею в діалоговому режимі.
Обладнання,через яке здійснюється доступ до контрольованих ресурсів (ресурси мережіІнтернет на рис. 1), фізично відключається гіпервізор від обчислювальноїВМ. Це обладнання управляється другий – сервісної – віртуальною машиною, яка,взагалі кажучи, може виконуватися прихованим для користувача чином у фоновомурежимі. Системні виклики окремих (довірених) процесів перехоплюютьсягіпервізор, і ті з них, які відносяться до контрольованих ресурсів, передаютьсяна обслуговування (обслуговуються віддалено) в сервісну ВМ. Зауважимо, щообслуговування цих викликів всередині обчислювальної ВМ неминуче призведе допомилки через відсутність у неї можливостей (обладнання) здійснити доступ довідповідних ресурсів. Решта системні виклики довірених процесів, а також всісистемні виклики інших процесів, обслуговуються засобами ОС в обчислювальнійВМ.
/>
Рисунок1. Делегування системних викликів другий віртуальній машині
Приперехопленні системного виклику гіпервізор може проконтролювати допустимістьконтексту, з якого виконується запит на системний виклик, тобто чи дозволенийданому процесу доступ до такої категорії ресурсів, і виконувати віддаленеобслуговування виклику тільки у випадку успішного проходження перевірки.Аналізуючи параметри виклику, гіпервізор може також здійснювати більш тонкийконтроль доступу до ресурсу, наприклад, дозволяти мережевий доступ тільки дообмеженого числа комп'ютерів в мережі, що мають задані адреси.
Уданій роботі описується архітектура і деталі реалізації механізму віддаленоговиконання системних викликів, що використовується в системі безпеки, якапредставлена в роботі [3]. У ній контрольованими ресурсами є виключно ресурсимережі Інтернет. Як наслідок, реалізація, що розглядається в даній роботі,допускає віддалене обслуговування тільки тих системних викликів, які можутьбути використані при мережевому взаємодії через сокети. Однак, враховуючиспільність подання сокетів і файлів для користувацького процесу у виглядідескрипторів файлів і, як наслідок, спільність багатьох системних викликів,аналізований механізм в цілому придатний також для тих сценаріїв, коликонтрольованим ресурсом є файлова система.
Окремікомпоненти системи, що розглядається у даній роботі, можуть такожвикористовуватися для ефективного вирішення тих завдань, в яких потрібновиконувати трасування системних викликів. Справа в тому, що штатні механізмитрасування в ОС Linux (ptrace) базуються на сигналах, що посилаються ядром ОСпроцесу-монітора (відладчик) при виконанні відлагоджує процесом системноговиклику, що призводить до частого перемикання контексту процесів (монітора ітрасуванню процесу). Крім того, читання даних з адресного простору трасуваннюпроцесу можливе тільки порціями по 4 байти. Розміщення монітора процесів нарівні гіпервізора дозволяє усунути вказані обмеження.
Завданнявіддаленого виконання системних викликів розглядається також в рамках проектуVirtualSquare [6]. Відмінність запропонованого нами підходу полягає увикористанні технології апаратної віртуалізації для перехоплення системнихвикликів. Крім того, в роботі [6] підмножина системних викликів, виконуванихвіддалено, задається жорстко, у той час як у нашому підході рішення провіддалений виконання системного виклику приймається, виходячи з дескриптораресурсу, до якого звертається процес. У ряді випадків системний виклик требаодночасно виконувати в обох системах (локальної та дистанційної) з наступнимоб'єднанням результатів, і це питання також розглянуто в даній роботі.
Механізмвіддаленого виконання системних викликів близька механізму віддаленоговиконання процедур [7], широко вживаному в розподілених програмних системах,зокрема, в мережевої файлової системи NFS [8]. Принципова відмінність пропонованогонами рішення полягає у відсутності необхідності модифікації (в тому числі,перекомпіляції) коду програми і операційної системи для обслуговуваннясистемних викликів в іншій системі.
Статтяорганізована наступним чином. У розділі 2 представлено короткий оглядтехнології апаратної віртуалізації і викладена загальна архітектура системи таїї компонент. У розділі 3 детально розглянуті принципи роботи системи і обробкарізних сценаріїв доступу до ресурсів. У розділі 4 представлені результатианалізу продуктивності системи як на синтетичних тестах, так і на реальнихдодатках. У розділі 5 підводяться підсумки роботи.
1. Архітектура системи
Технологіявіртуалізації дозволяє виконувати ОС в апаратній віртуальній машині (ВМ) підуправлінням порівняно невеликий за розміром системної програми – моніторавіртуальних машин (гіпервізора) [5]. Апаратна віртуальна машина є ефективнийізольований дублікат реальної машини, і виконання в ній операційної системи невимагає внесення будь-яких змін в код ОС. Гіпервізор повністю контролюєвзаємодію ОС в ВМ з устаткуванням і може забезпечити надійну ізоляцію ВМ,спираючись на апаратні механізми захисту.
Функціонуваннягіпервізора та організація виконання віртуальної машини багато в чому схожі зтим, як операційна система керує виконанням користувацьких процесів. Гіпервізорініціалізує системні структури даних, необхідні обладнанню, і виконуєспеціальну інструкцію VMRUN, що реалізовує запуск ВМ і передачу управліннявідповідної інструкції коду ОС. При виникненні апаратного події (переривання)або при виконанні операційною системою привілейованої інструкції (у тому числі,системного виклику) виконання ВМ переривається, і управління передаєтьсягіпервізор на наступну інструкцію після VMRUN. Після обробки перехопленогоподії гіпервізор відновлює виконання ВМ.
Архітектурасистеми виглядає наступним чином. Гіпервізор реалізує одночасне виконання двохвіртуальних машин (мал. 1), що працюють під управлінням операційної системиLinux однаковою. Відзначимо, що операційні системи у віртуальних машинах можутьбути різними, якщо гіпервізор при цьому забезпечує необхідне перетвореннясистемних викликів між вихідної та цільової операційними системами. Уобчислювальної ВМ виконуються процеси користувача, серед яких виділено набірдовірених процесів. Гіпервізор надає довіреною процесам привілей доступу доресурсів, що обслуговується ОС в сервісній ВМ (контрольованим ресурсів); іншіпроцеси доступу до цих ресурсів не мають. Доступ довірених процесів доконтрольованих ресурсів проводиться за допомогою перехоплення їх системнихвикликів і, при необхідності, їх перенаправлення для обслуговування в сервіснуВМ.
Обидвівіртуальні машини виконуються асинхронно, і обчислювальна ВМ не блокується начас віддаленого обслуговування системного виклику. У цей час процес, якийініціював системний виклик, знаходиться в стані очікування, а всі інші процесив обчислювальній ВМ продовжують виконуватися нормальним чином. Більш того,система допускає одночасне обслуговування декількох віддалених системнихвикликів, що надходять від різних довірених процесів.
Приперехопленні запиту процесу на виконання системного виклику гіпервізор копіюєвсі вхідні параметри виклику у власну область пам'яті і передає запит наобслуговування виклику в сервісну ВМ. Системний виклик може бути блокуючим(наприклад, read), і час його виконання в загальному випадку не обмежена. Дляуникнення блокування всієї обчислювальної ВМ на час обслуговування викликупроцес, який ініціював системний виклик, переводиться в стан очікування,дозволяючи іншим процесам продовжити своє виконання. При надходженні зсервісної ВМ результатів обслуговування виклику гіпервізор перериває виконанняобчислювальної ВМ, виводить процес зі стану очікування і копіює результати вйого адресний простір. Перебування процесу в стані очікування реалізуєтьсяштатними засобами ОС в ВМ без вмешівательства в роботу механізму управлінняпроцесами в операційній системі.
Всерединісервісної ВМ виконується набір процесів – делегатів, які є екземплярамиспеціалізованої програми. Кожен із делегатів обслуговує запити на системнівиклики окремого довіреної процесу з обчислювальної ВМ, причому ієрархіяделегатів в сервісній ВМ відповідає ієрархії довірених процесів вобчислювальній ВМ. Новий делегат породжується кожного разу при створенні новогодовіреної процесу і знищується при завершенні роботи цього процесу.
Виконанняделегата полягає в циклічному виконанні системних викликів, що надійшли відвідповідного довіреної процесу, і сповіщення гіпервізора про результати(делегат, на відміну від довіреної процесу, знає про існування гіпервізора).Делегати отримують запит на виконання системного виклику від спеціалізованогопроцесу – диспетчера – через механізм взаємодії між процесами (чергаповідомлень). Всі запити, що надходять від гіпервізора, проходять черезпроцес-диспетчер. Диспетчер відстежує відповідності між ідентифікаторамидовірених процесів і ідентифікаторами делегатів і, отримавши запит відгіпервізора на обслуговування системного виклику деякого довіреної процесу,перенаправляє його відповідного делегату. Подальше обслуговування запиту цілкомпроводиться делегатом без участі диспетчера. Зокрема, делегат самостійновиконує доступ до сховища, сповіщає гіпервізор про результати системноговиклику і т.д.
Ієрархіякожного довіреної процесу сходить до службового процесу, що є екземпляромспеціальної користувацької програми – монітора. Перший довірений процес завждипороджується монітором. Монітор, у свою чергу, не є надійною програмою.Завдання монітора складається у запуску нового (в тому числі, першого)довіреної процесу та відстеження його стану, а також стану всіх його дочірніхпроцесів, частина з яких можуть бути довіреними, а частина – ні.
Моніторреалізований на базі стандартного інтерфейсу налагодження ptrace. Моніторперехоплює події породження та завершення процесів, в тому числі, аварійного,наприклад, при отриманні сигналу процесом, для якого у нього не зареєстрованийобробник. При виконанні одним з дочірніх процесів системного виклику fork абоexec монітор визначає, чи треба даному процесу виконання у довіреному режимі(тобто чи буде новий процес довіреною), і, у разі необхідності, може вимагатигіпервізор про його включення для процесу. При завершенні довіреної процесумонітор також сповіщає про це гіпервізор.
/>
Рисунок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) за заданими адресами повинні бути записанівихідні дані, якщо вони є.
Гіпервізорвиводить процес зі стану очікування за допомогою вкидання іншого синхронногопереривання в обчислювальну ВМ, обробник якого звільняли семафор і, тим самим,відновлює виконання процесу. Процес далі виконує гіпервизов на запитрезультатів системного виклику. Зауважимо, що хоча гіпервизов проводиться зконтексту ядра, в точці гіпервизова на апаратурі завантажені власні таблиціприписки довіреної процесу. Гіпервізор переглядає таблиці і перевіряє, щовіртуальні адреси, за якими мають бути записані результати, відображені нафізичну пам'ять, і доступ до цих адресами відкрито по запису. Наявність доступутільки з читання може означати, що дана область пам'яті є «копійований приоперації запису». При наявності доступу по запису до всього необхідногодіапазону адрес гіпервізор копіює результати виконання системного виклику зісховища в адресний простір процесу і відновлює виконання ВМ. В іншому випадкугіпервізор для всіх необхідних віртуальних сторінок вкидає у ВМ виключення«помилка сторінки», що дає ОС вказівку виділити пам'ять для відповідноївіртуальної сторінки і відобразити її на фізичну пам'ять.
Привіддаленому обслуговуванні системного виклику делегат може отримати сигнал відОС в сервісній ВМ, наприклад, сигнал SIGPIPE про розрив мережевого з'єднання. Уцьому випадку делегат сповіщає гіпервізор про здобутий сигналі, і гіпервізордоставляє сигнал довіреній процесу. Для цього він інформує про сигнал модульядра ОС, який, у свою чергу, доставляє сигнал процесу засобами API ядра ОСLinux. Доставка процесу сигналу може привести до його аварійного завершення. Уцьому випадку монітор повідомить гіпервізор про закінчення виконання процесу, ігіпервізор звільнить пам'ять, відведену під службові структури даних.
2.1 Точка обслуговування системного виклику
Упереважній більшості випадків системний виклик може бути асоційований зресурсами якої-небудь однієї з віртуальних машин або на підставі номерасистемного виклику, або на підставі його параметрів. Зокрема, системний викликsocket, що створює кінцеву точку для мережевої взаємодії і повертає файловийдескриптор для роботи з нею, повинен обслуговуватися в сервісній ВМ. Системнийвиклик write вимагає додаткового аналізу файлового дескриптора, що передаєтьсяв параметрах дзвінка. Якщо дескриптор асоційований з сокетом, то він повиненобслуговуватися в сервісній ВМ, в іншому випадку – в обчислювальній ВМ.
ОС вобох ВМ підтримують набори файлових дескрипторів для довіреної процесу і йогоделегати незалежно один від одного. Якщо гіпервізор після віддаленогообслуговування системного виклику поверне довіреній процесу ідентифікаторфайлового дескриптора, отриманого від делегата, без будь-яких змін, то це можепризвести до наявності в пам'яті довіреної процесу двох ідентичнихдескрипторів, які насправді відповідають різним ресурсів в тій і іншій ВМ. Уподальшому, при виконанні довіреною процесом системного виклику для такогодескриптора гіпервізор не зможе розрізнити, чи відноситься виклик до локальногоресурсу в обчислювальній ВМ або віддаленого в сервісній ВМ.
Длявирішення цієї проблеми гіпервізор реалізує додатковий рівень абстракціїфайлових дескрипторів для довірених процесів. Файлові дескриптори, щозберігаються в пам'яті довіреної процесу (в якихось змінних), являють собою нереальні дескриптори, призначені ядром ОС в обчислювальній або сервісній ВМ, аіндекси в таблиці віддалених ресурсів, підтримуваної гіпервізора. Гіпервізорперехоплює і обробляє всі системні виклики довіреної процесу, у яких вхідні абовихідні параметри містити файлові дескриптори. Якщо параметр вхідний, тогіпервізор витягує з таблиці віддалених ресурсів фактичний файловий дескриптор,модифікує параметри системного виклику і передає його на обслуговування тієїВМ, яка є власником ресурсу з цим дескриптором. Якщо параметр вихідний, тогіпервізор створює новий запис у таблиці віддалених ресурсів, позначаючи, яка звіртуальних машин є власником ресурсу, і модифікує вихідні параметри процесу,підставляючи індекс створеної запису замість фактичного значення дескриптора.Компонента гіпервізора, що відповідає за обробку файлових дескрипторів,враховує особливості виділення вільних дескрипторів ОС Linux, включаючи нюансироботи системних викликів dup2 і fcntl. Таким чином, за значенням, передаєтьсядовіреною процесом, завжди можна визначити віртуальну машину – власника ресурсута номер файлового дескриптора в її контексті.
Уряді випадків виконання системного виклику може задіяти ресурси обох ВМ.Зокрема, параметри системного виклику select і його аналогів, а саме, наборифайлових дескрипторів, для яких процес очікує виникнення відповідних подій,можуть одночасно ставитися до ресурсів як обчислювальної, так і сервісної ВМ.Такий виклик повинен обслуговуватися одночасно в обох ВМ, інакше програма можеперестати виконуватися коректно. При цьому системний виклик в кожнійвіртуальній машині повинен обслуговуватися тільки з тими параметрами (файловийдескриптор), які відносяться до ресурсів даної ВМ.
Приперехопленні запиту на виконання системного виклику, що вимагає одночасноговиконання в обох ВМ, гіпервізор, використовуючи таблицю віддалених ресурсів,розшивають фактичні параметри на два непересічних набору (по одному для кожноїз ВМ) і виконує виклик одночасно в обох ВМ з відповідними наборами параметрів.Модифікований набір параметрів записується в пам'ять довіреної процесу поверхоригінального. Перед поверненням управління процесу (після обслуговуваннясистемного виклику) гіпервізор відновлює вихідний набір параметрів, можливо,коректуючи його з урахуванням результатів системного виклику, отриманих зсервісної ВМ. Підсумковим результатом виконання системного виклику є результаттієї ВМ, яка хронологічно першою закінчила виконання своєї частини виклику,результати другий ВМ відкидаються.
Післяотримання результатів від однієї з ВМ гіпервізор виробляє скасування виконаннясистемного виклику в іншій ВМ. Механізм скасування виконання системного викликуреалізований в обох віртуальних машинах по-різному. У разі обчислювальної ВМмодуль ядра посилає довіреній процесу певний сигнал (не використовуєтьсяпроцесом). При цьому модуль системи захисту безпосередньо перед посилкою сигналуреєструє для процесу спеціальний «порожній» обробник сигналу, що представляєсобою адресу RET інструкції в коді довіреної програми. Адреса інструкціївказується в паспорті завдання. Реєстрація обробника гарантує, що посилкасигналу не призведе до аварійного останову процесу. У сервісній ВМ всі системнівиклики, які можуть виконуватися одночасно в обох ВМ, виконуються в окремомупотоці (нитки) делегати. Скасування виконання системного виклику проводиться задопомогою примусового завершення цього потоку.
3. Продуктивністьсистеми
Описанав цій роботі система реалізована на базі монітора віртуальних машин KVM [9].KVM включений в основну гілку розробки ядра ОС Linux і являє собою модуль, щодинамічно завантажений в ядро базової (хост) операційної системи Linux.Управління виконанням ВМ реалізується спільно ядром хост системи, модулем KVMта користувацький програмою QEMU. QEMU віртуалізується периферійні пристрої тазабезпечує спільний доступ віртуальних машин до обладнання, встановленого накомп'ютері і керованого базовою системою.
Реалізація,представлена в цій роботі, побудована на базової операційної системи Linux зядром версії 2.6.31.6 і моніторі віртуальних машин KVM версії 88. Сумарнийобсяг коду компонент системи складає близько 16 тис. рядків. Віртуальні машинивиконуються під управлінням ОС Linux з дистрибутива Fedora версії 9 зі штатнимядром версії 2.6.27.12–78.2.8.fc9.i686. На комп'ютері встановленийчотирьохядерних процесор Phenom 9750 компанії AMD з тактовою частотою 2.4 Ггц і2 Гбайта оперативної пам'яті. Даний процесор підтримує технологію апаратноївіртуалізації, включаючи віртуалізацію пам'яті на базі вкладених (NPT) таблицьприписки віртуальної машини. Базова операційна система використовує всі чотириядра процесора (ядро базової ОС зібрано в SMP-конфігурації). Кожній віртуальніймашині виділяється по одному віртуальному процесору і по 512 Мбайт оперативноїпам'яті.
Дляпроведення ряду тестів використовується другий комп'ютер такої ж конфігурації.В обох комп'ютерах встановлені 100 Мбіт-ві мережеві адаптери, пов'язані один зодним через мережевий концентратор (хаб). До концентратора підключені тількидані дві машини.
Доступвіртуальної машини до мережі здійснюється за допомогою створення в базовій ОСштатними засобами ядра ОС програмного мережевого інтерфейсу (TAP0). Цейінтерфейс є образом мережевого інтерфейсу (ETH0) віртуальної машини в базовійсистемі. Прив'язка інтерфейсу TAP0 до фізичної середовищі здійснюється черезпрограмний Ethernet-міст (bridge) в ядрі базової ОС, також організовуванийштатними засобами ОС Linux. Така конфігурація (мал. 1) дозволяє відкрити ВМ дляінших машин в мережі, на відміну від конфігурації QEMU за замовчуванням, щоприховує ВМ від інших машин в мережі за допомогою механізму трансляціїмережевих адрес (NAT) і роздільної лише вихідні з'єднання в ВМ.
Длятестування продуктивності ми використовували чотири спеціально розробленихсинтетичних тесту, моделюючих «важкі» для системи сценарії використання, і тритипових програми: утиліту тестування продуктивності мережі TTCP, програмувіддаленого доступу SSH і веб-сервер Apache.
Синтетичнітести засновані на виконанні системного виклику select () з одним або двомафайловий дескриптор. Один з дескрипторів (локальний), позначимо його LocalFD,являє собою файл, відкритий в контексті обчислювальної ВМ, другий (віддалений),позначимо його RemoteFD, – сокет, створений в сервісній ВМ. У всіх тестах, крімпершого, виконання системного виклику вимагає взаємодії між ВМ. Тестизапускаються з контексту обчислювальної ВМ.
/>
Рисунок5. Конфігурація мережі для тестування продуктивності.
Обрамленнядескриптора квадратними дужками означає, що запитувана операція не може бутивиконана для даного ресурсу, і системний виклик заблокує виконання відповідногокористувацького процесу в одній з ВМ. Відсутність квадратних дужок означаєможливість виконання операції і негайне повернення управління для користувачапроцесу. Тоді синтетичні тести перевіряють наступні сценарії виконаннясистемного виклику:
· select (LocalFD);
· select (RemoteFD);
· select (LocalFD,[RemoteFD]);
· select ([LocalFD],RemoteFD).
Виконаннясистемного виклику select (LocalFD) не вимагає взаємодії між віртуальнимимашинами і характеризує «обчислювальні» накладні витрати усерединіобчислювальної ВМ на перехоплення системних викликів, аналіз фактичнихпараметрів та ін Виконання системного виклику select (RemoteFD) показуєсумарний час, необхідне на доставку запиту делегату в сервісну ВМ, виконання системноговиклику в ній і повернення результатів процесу, яка перебуває весь цей час устані очікування.
Виконаннясистемного виклику select з двома дескрипторах включає в себе взаємодію міжвіртуальними машинами і, крім того, вимагає виконання скасування системноговиклику в тій ВМ, в якій процес був заблокований, а саме, в тій ВМ, дескрипторресурсу якої обрамлений квадратними дужками. Слід відзначити принциповувідмінність третього і четвертого тесту. У тесті select (LocalFD, [RemoteFD])скасування системного виклику, виконуваного делегатом в сервісній ВМ,проводиться асинхронно для процесу в обчислювальній ВМ, і він може продовжитисвоє виконання, не чекаючи підтвердження від мережевої ВМ. Така оптимізаціяможлива, оскільки для нормального продовження виконання процесу доситьрезультатів, одержуваних локально від ядра обчислювальної ВМ. У свою чергу, втесті select ([LocalFD], RemoteFD) процес не може продовжити виконання, покивиконання системного виклику не буде перервано, що призводить до додаткових накладнихвитрат.
Утаблиці 1 вказано час виконання тестів (у секундах) у циклі з 100 тисячітерацій. Перший рядок таблиці характеризують виконання тесту select (LocalFD)в базовій системі. Другий рядок показує час виконання тесту select (LocalFD) уВМ із включеним механізмом відстеження виконання процесу. Зростання часувиконання на один порядок обумовлено витратами на перехоплення інструкції INTn,що ініціює системний виклик і, головне, інструкції IRET, що реалізує поверненняв призначений для користувача режим як з системного виклику, так з обробниківпереривань. Ми очікуємо, що за рахунок адаптації пропонованої системи підмеханізм швидкого виконання системних викликів (SYSCALL / SYSRET),підтримуваний сучасними процесорами сімейства x86, даний показник може бутипокращено.
Показнику третьому рядку таблиці говорить про те, що власне обчислювальні витратисистеми (за винятком перехоплення двох інструкцій) складають близько 20%.Четвертий рядок характеризує накладних витрати на асинхронну скасування частинисистемного виклику, виконуваної делегатом в сервісній ВМ. Відзначимо, що кількапослідовних операцій скасування також виконуються асинхронно, і синхронізаціяздійснюється тільки при наступному виконанні «істотного» (не скасовується)віддаленого системного виклику. Крім того, делегат не буде виконувати системнийвиклик, якщо виявить, що для нього вже надійшла команда на скасування. Такеможливо в силу асинхронності виконання віртуальних машин.
Утесті select (LocalFD, [RemoteFD]) синхронізація здійснюється тільки післявихід з циклу при закритті «віддаленого» сокета (системний виклик close). Принаявності великої кількості послідовно скасованих системних викликів (100 тисячв даному випадку) така операція синхронізації може займати тривалий час, що йвідбито в таблиці. Безпосередньо при виході з основного циклу час виконаннятесту складає всього 15 секунд. Подальша операція закриття сокета, що вимагаєсинхронізації операцій скасування, вимагає додаткових 16 секунд.
Останнідва рядки таблиці характеризують повноцінне віддалене обслуговування системноговиклику. Шостий рядок таблиці показує накладні витрати на скасування локальноїчастини системного виклику в обчислювальній ВМ, яка завжди виконуєтьсясинхронно для процесу.
Таблиця1. Час виконання синтетичних тестівТест Час (сек.) Базова система 1 Віртуальна машина 9 select(LocalFD) 11 select (LocalFD, [RemoteFD]) 15 (31) select(RemoteFD) 189 select([LocalFD], RemoteFD) 253
Синтетичнітести показують, що при найгіршому сценарії час виконання системного викликуможе зростати до 250 разів. Однак на практиці це не робить істотного впливу начас виконання програми в цілому. По-перше, більшість системних викликів, щовимагають видаленого виконання, включає в себе передачу даних черезпериферійний пристрій (зокрема, через мережу). По-друге, додаток, як правило,виконує також інші дії, які нівелюють дані накладні витрати, наприклад, вономоже часто перебуває у стані очікування відкриття семафора.
Намалюнку 6 наведено результати тестування системи на утиліті TTCP, що виконує вциклі передачу пакетів між двома машинами в мережі. Перша діаграма відповідаєоригінальній TTCP утиліті, друга – модифікованої, в яку ми додали виконаннясистемного виклику select перед кожною посилкою пакета. Системний виклик selectв даному випадку виконується віддалено, тобто відповідає синтетичному тестуselect (RemoteFD). При виконанні оригінальної утиліти накладні витрати навіддалене обслуговування системних викликів склали всього 2% від сумарного часувиконання програми. Додавання системного виклику select збільшило накладнівитрати до 31%, однак навіть у цьому випадку вони значно менше витрат всинтетичному тесті select (RemoteFD), де час виконання збільшилося в 189 разів.
Митакож тестували пропоновану систему на утиліті віддаленого доступу SSH задопомогою копіювання файлу між двома машинами в мережі, а також на веб-серверіApache, запускаючи для нього пакет тестів навантажувального тестування Flood. Вобох випадках час виконання тестів варіювалося в межах 1% від їх виконання набазовій системі. Таким чином, ми вважаємо, що пропонований механізм віддаленогообслуговування системних викликів є досить ефективним для його використання впромислових завданнях.
/>
Рисунок6. Час виконання утиліти TTCP (сек)
Висновок
Уданій роботі представлено підхід до віддаленого виконання системних викликівкористувацького процесу, що не вимагає внесення будь-яких змін (у тому числі,перекомпіляції) ні в код процесу, ні в код операційної системи. Особливістюрозглянутого підходу є те, що процесу може бути наданий контрольований доступдо таких ресурсів, до яких операційна система, під управлінням якої виконуєтьсяпроцес, ні прямої, ні опосередкованої доступу не має. Це дозволяє надаватиселективний доступ до ресурсів, що вимагає контролю (наприклад, мережіІнтернет), окремим довіреною користувальницьким процесам, залишаючи в той жечас ці ресурси недоступними іншим процесам і навіть ядру операційної системи.
Пропонованийпідхід заснований на виконанні операційної системи (і керованих нею процесів)всередині апаратної віртуальної машини. Монітор віртуальних машин (гіпервізор)перехоплює системні виклики окремих довірених процесів і при необхідностіпередає їх на обслуговування сервісної машині. Сервісна машина може бути іншийвіртуальною машиною, виконується паралельно, або іншої фізичної машиною, з якоюу гіпервізора є канал зв'язку.
Розглянутийпідхід реалізовано на базі монітора віртуальних машин KVM. В якості сервісноїмашини використовувалася паралельно виконує віртуальна машина, а в якостіконтрольованих ресурсів було вибрані мережеві ресурси (у т.ч. ресурсиІнтернету). Тестування продуктивності системи показало, що на реальних додаткахнакладні витрати на віддалене обслуговування системних викликів укладаються вмежі 3 відсотків.
Література
1.Tanenbaum, A.S., Herder, J.N.,Bos, H. Can We Make Operating Systems Reliable and Secure?.. Computer 39, 5 (May2006), pp. 44–51.
2.Burdonov, I., Kosachev, A., Iakovenko,P. Virtualization-based separation of privilege: working with sensitive data inuntrusted environment. In Proceedings of the 1st Eurosys Workshop onVirtualization Technology for Dependable Systems, New York, NY, USA, 2009, ACM,pp. 1–6.
3.Яковенко П.М. Контрольдоступу процесів до мережевих ресурсів на базі апаратної віртуалізації. Методиі засоби обробки інформації. Праці Третьої Всеросійської наукової конференції,М, 2009, стор 355–360.
4.Chen, X., Garfinkel, T.,Lewis, E.C., Subrahmanyam, P., Waldspurger, C.A., Boneh, D., Dwoskin, J.,Ports, D.R. Overshadow: a virtualization-based approach to retrofittingprotection in commodity operating systems. In Proceedings of the 13thinternational Conference on Architectural Support For Programming Languages andOperating Systems, ACM, 2008, pp. 2–13.
5.Adams, K., Agesen, O. Acomparison of software and hardware techniques for x86 virtualization. InProceedings of the 12th international Conference on Architectural Support ForProgramming Languages and Operating Systems, ACM, 2006, pp. 2–13.
6.VirtualSquare: Remote SystemCall.
7.Sun Microsystems, Inc. RPC:Remote Procedure Call. Protocol Specification. Version 2. Network workinggroup. RFC 1057. 1988.
8.Sun Microsystems, Inc. NFS:Network File System Protocol Specification. Network working group. RFC 1094.1989.
9.Shah. A. Deep Virtue:Kernel-based virtualization with KVM. Linux Magazine (86), 2008, pp. 37–39.