Механізм обслуговування системних викликів (стр. 5 из 5)

У таблиці 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 (May 2006), pp. 44–51.

2.Burdonov, I., Kosachev, A., Iakovenko, P. Virtualization-based separation of privilege: working with sensitive data in untrusted environment. In Proceedings of the 1st Eurosys Workshop on Virtualization 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 retrofitting protection in commodity operating systems. In Proceedings of the 13th international Conference on Architectural Support For Programming Languages and Operating Systems, ACM, 2008, pp. 2–13.

5.Adams, K., Agesen, O. A comparison of software and hardware techniques for x86 virtualization. In Proceedings of the 12th international Conference on Architectural Support For Programming Languages and Operating Systems, ACM, 2006, pp. 2–13.

6.VirtualSquare: Remote System Call.

7.Sun Microsystems, Inc. RPC: Remote Procedure Call. Protocol Specification. Version 2. Network working group. 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.