Июль 28

Введение в виртуализацию Xen Project

Об авторе: Ларс Курт — увлеченный менеджер сообщества Xen с длинной историей сотрудничества с open-source-сообществами, такими как Symbian, Symbian DevCo, Eclipse и GNU. Он имеет девятилетний опыт работы по построению и управлению инженерными командами, а также 16-летний опыт работы в сфере вспомогательных программных средств и мобильных телефонов в компаниях ARM, Symbian Ltd., Symbian Foundation и Nokia.

Эту статью Ларс подготовил на основе своего выступления на Root Linux Conference 2017 — ежегодной конференции embedded- и Linux-разработчиков.

Автор перевода: Юрий Коноваленко, Associate Manager, GlobalLogic.

Технологии постоянно движутся в направлении уменьшения объемов занимаемой памяти, более мощных функциональных возможностей и взаимодействия. Виртуализация — возможность запуска нескольких копий операционной системы или даже нескольких операционных систем на одном компьютере или хосте — является ключом к развитию этой тенденции. В этой статье я расскажу о преимуществах виртуализации, познакомлю вас с Xen Project (единственным в мире оупенсорсным гипервизором первого типа — без операционной системы). Кроме того, мы поговорим об использовании виртуализации в разных доменах.

Зачем нужна виртуализация?

Тремя основными областями использования виртуализации являются облака/серверы, приложения для обеспечения безопасности и встроенные системы/автомобилестроение. Прежде чем углубиться в специфику использования Xen Project на примере конкретных случаев, давайте кратко рассмотрим преимущества виртуализации по каждой из упомянутых выше областей.

Облако/серверы

Основная причина виртуализации серверов заключается в консолидации аппаратных средств, увеличении плотности рабочей нагрузки, экономии энергии и освобождении пространства центра обработки данных. Еще одним интересным побочным эффектом виртуализации является то, что она позволяет быстрее запускать ОС на виртуальной машине (VM). Раньше вам пришлось бы создавать каждый сервер отдельно, разбираться со всеми кабелями, а потом еще и устанавливать ОС и программное обеспечение для каждого из серверов. Сегодня же вы можете использовать простой пользовательский интерфейс инициализации, который работает с гипервизором на предварительно установленном кластере серверов.

Также благодаря виртуализации вы получаете дополнительную гибкость. Меньше зависите от конкретных аппаратных средств — это означает, что вы можете запускать разные операционные системы на одном сервере. И, конечно же, все стандартные решения для виртуализации имеют функциональность, которая помогает увеличить время безотказной работы (например, живая миграция, миграция хранилища, функционал для обеспечения высокого уровня доступности и т. д.).

Приложения для обеспечения безопасности

Использование гипервизора более безопасно, чем запуск приложения на традиционном сервере, а Xen еще более безопасен, поскольку является гипервизором первого типа. Его архитектура имеет более сильную изоляцию между гипервизором и гостевым ядром, по сравнению с другими гипервизорами. Также в нем есть следующие преимущественные особенности, которые более комплексно отделяют систему для уменьшения риска заражения эксплойтами:

Таблицы грантов управляют доступом к памяти, которая выделена для каждой VM, а также позволяют контролировать распределение памяти между виртуальными машинами, создавая более надежную границу безопасности вокруг них и делая невозможным переход эксплойтов с одной виртуальной машины на другую.
Дезагрегирование Xen позволяет вам изолировать определенные основные функции гипервизора в отдельной виртуальной машине (мы почти всегда используем VM как процессы, в качестве следующего уровня изоляции). Особый вариант использования — это так называемый «Secure I/O», который позволяет запускать отдельные драйверы устройств на виртуальных машинах.
Функция самодиагностики виртуальной машины (VMI), которая является эксклюзивной для Xen, обнаруживает новые классы угроз безопасности системы и уже используется в ряде различных коммерческих продуктов.

Встраиваемые системы / автомобилестроение

Рынки встраиваемых систем и автомобилестроения также используют виртуализацию для консолидации, но не так, как серверы. Ранее устройства содержали несколько различных систем на кристалле (SoCs), каждая из которых запускала разные приложения и операционные системы, теперь же все объединено в единую SoC. Поскольку эти новые устройства в настоящее время все меньше зависят от аппаратных средств, производители получают те же преимущества гибкости системы, что и серверы. Разумеется, производители встроенных систем и автомобилей должны удовлетворять многие дополнительные требования, выдвигаемые рынком (например, требования времени выполнения, сертификатов безопасности, поддержки конкретных устройств ввода/вывода и т. д.). В этом случае на помощь приходят такие технологические партнеры, как GlobalLogic, отлично знающие Xen.

Примечание о схожести сценариев использования виртуализации в разных областях

С моей стороны было бы упущением не отметить, что, хотя указанные три рынка и являются главными приверженцами виртуализации, их некогда присущие только им сценарии использования виртуализации уже не настолько уникальны. В то время как в прошлом Xen Project принимал код для разных сценариев, за последние несколько лет мы заметили, что многие сценарии подходят не только для одной конкретной области. Например, после откровений Сноудена к безопасности стали относиться гораздо серьезнее. Как следствие, функционал гипервизора, который первоначально был разработан экспертами по безопасности для Xen Project, в настоящее время развернут во многих сегментах рынка. Кстати, эти же технологии безопасности используются в области встроенных систем и автомобилестроения.

Это касается и уменьшения времени задержки, которое было первоначально критичным для разработчиков встроенных приложений. Теперь оно стало важным для графических рабочих нагрузок в облачных вычислениях и для виртуализации сетевых функций (NFV). Вследствие того, что эти требования и технологии схожи, организации из разных сегментов рынка начинают активно сотрудничать. И, конечно же, в результате этого сотрудничества выигрывает все сообщество Xen, как вы можете убедиться, глядя на рисунок ниже.

Рисунок 1. Поскольку такие функции, как безопасность, задержка и схожесть сценариев использования, становятся одинаково важными для всех поклонников виртуализации, организации из разных сегментов рынка начинают сотрудничать для развития функционала, который будет полезен всему сообществу Xen

Что отличает гипервизор Xen Project?

В традиционном гипервизоре типа 1 драйверы устройств встроены в сам гипервизор. В Xen существует специальная VM под названием Dom0, которая запускает ядро Dom0 и позволяет Xen по умолчанию использовать драйверы устройств ядра Dom0. Вот пример того, как работает эта модель:

VM1 обращается к внешнему драйверу.
Внешний драйвер обращается ко внутреннему драйверу в Dom0 через протокол PV.
Внутренний драйвер обращается к драйверу исходного устройства в Linux или другой ОС, поддерживающей Dom0.
Затем драйвер исходного устройства уже обращается к самому аппаратному оборудованию.

Предположим, мы рассматриваем сетевой трафик: тогда VM1 будет обращаться к фронтенду виртуального драйвера сети (netfront driver), который, в свою очередь, обращается к бэкенду виртуального драйвера сети (netback driver), который уже обращается к исходному сетевому драйверу (native driver). (Это также называется паравиртуализацией). И, конечно же, вся модель повторяется на нескольких разных виртуальных машинах. Кроме того, Dom0 также является вашим интерфейсом во внешний мир: так называемый компонент Toolstack позволяет вам управлять всей системой.

Рисунок 2. Гипервизор Xen типа 1 стоит поверх аппаратного обеспечения, а Dom0 VM позволяет Xen использовать исходные драйверы устройств ядра Dom0

Как я упоминал ранее, три основные области, где внедрена виртуализация, — это облако/серверы, приложения для обеспечения безопасности и встраиваемые системы / автомобилестроение. Теперь давайте рассмотрим, какую пользу приносит Xen каждому отдельно взятому сектору.

Варианты использования: облако/серверы

Еще в конце 2014 — начале 2015 года две уязвимости в Xen привели к тому, что Amazon перезапустил 10 % своего облака. Важно отметить, что ни одна часть облака во время облачной перезагрузки не подверглась атаке уязвимости нулевого дня, поскольку провайдеры облачных вычислений устранили основные проблемы Xen до того, как информация стала общедоступной. Однако это был важный урок, который мы выучили, и он заключался в том, что допускать причинение неудобств пользователям облачных вычислений по причине перезагрузки просто неприемлемо.

Поэтому вместе с Amazon, Alibaba, Citrix, Oracle, SUSE мы разработали решение, которое позволило нам патчить гипервизор во время его работы, чтобы избежать перезагрузки Xen после применения исправлений к любым уязвимостям. Подход к этому новому решению патчинга на лету (Live Patching) заключался в разработке инфраструктуры гипервизора, которая бы позволяла нам загружать бинарный код (то есть обновление), который бы заменял существующий код с гранулярностью в функции гипервизора. Мы также разработали инструменты для создания обновлений и инструменты для применения и удаления обновлений, а также перечень тех обновлений, которые были применены в прошлом.

Чтобы создать новое обновление, вам нужно иметь информацию о базовой структуре Xen с уникальным идентификатором сборки. Это важно, поскольку двоичные файлы Xen зависят от исходного кода, параметров компиляции и точной версии компилятора, используемых для его создания. Если вы хотите использовать патчинг на лету, вам нужно сохранить полную базовую структуру Xen, чтобы вы могли создавать обновления в будущем. Чтобы сделать это, примените патч к своей базовой структуре и используйте инструменты Live Patch для создания обновления. Затем вы можете применить обновление с помощью инструментов командной строки Xen. Обратите внимание, что обновления могут быть накопительными. Вы можете применить несколько обновлений. Вы также можете удалить ранее примененные обновления.

Мы смогли реализовать Live Patching всего за девять месяцев благодаря тесному сотрудничеству многих компаний. Эта функциональность была выпущена в коммерческом продукте всего шесть месяцев спустя, и сегодня Amazon, Rackspace и другие облачные провайдеры — все используют Live Patching.

Дополнительные ресурсы

Xen в контексте безопасности

Если вы погуглите «Xen», то обнаружите, что каждый второй результат поиска связан с уязвимостями Xen. Вы не увидите подобного количества негативного освещения в средствах массовой информации по KVM или VMware, что может натолкнуть вас на мысль о том, что Xen не очень безопасен. Однако подобные отзывы о Xen на самом деле свидетельствуют об обратном, ведь большие облачные сервисы, такие как Amazon, Alibaba, Tencent и SoftLayer, продолжают использовать Xen, в то время как другие гипервизоры остаются в стороне.

Учитывая вышесказанное, давайте рассмотрим некоторые точные данные об уязвимостях. На рисунке 3 вы можете видеть количество уязвимостей для Xen, Linux и QEMU (как прокси для KVM). В 2015 году мы столкнулись с большим количеством уязвимостей Xen — прямым следствием упомянутого ранее перезапуска облака (Cloud Reboot), и это побудило многих небезразличных к безопасности активно искать ошибки в Xen.

Рисунок 3. Сравнение количества уязвимостей, обнаруженных в Xen, Linux Kernel и QEMU (как прокси для KVM)

Интересно, что тенденция по Xen идет вразрез с тенденциями по Linux и QEMU. За последние два года количество уязвимостей Linux и QEMU действительно растет, а количество уязвимостей Xen остается стабильным или уменьшается. Рассматривая это в контексте встроенных систем, в котором Xen на ARM является самой важной платформой, вы заметите, что у Xen на ARM очень мало проблем с безопасностью. В 2016 году только 2 из 33 уязвимостей повлияли на Xen на ARM. Годом ранее было около шести. Большая часть упоминаний об уязвимостях Xen в средствах массовой информации касается исключительно Xen на x86.

Процесс устранения уязвимостей Xen

Важно отметить, что программное обеспечение всегда будет иметь уязвимости. Независимо от того, сколько раз вы тестируете или сколько проверок кода вы выполняете, уязвимости всегда будут. Поэтому важно иметь процедуру, которая бы позволяла пользователям Xen устранять уязвимости, прежде чем они станут общеизвестными. Это делается с помощью процесса контроля уязвимостей. Давайте рассмотрим процесс устранения уязвимостей Xen в сравнении с OpenStack, Linux Kernel, QEMU и Jailhouse (рис. 4).

Рисунок 4. В отличие от других гипервизоров, Xen предоставляет информацию об уязвимостях для всех, у кого есть продукт или услуга на Xen, до того, как информация станет общедоступной

Синие столбцы

Первые два синих столбца определяют, имеет ли проект отдельную группу реагирования для решения проблем безопасности или устранения уязвимости. Linux и QEMU интересны тем, что они используют процесс, который контролируется дистрибутивами безопасности OSS Openwall. Следствием этого является то, что эти проекты не имеют контроля над тем, кого они могут предварительно информировать о проблемах безопасности.

Последние два синих столбца показывают, какие проекты имеют дело с серьезными и несерьезными проблемами и какой тип процесса устранения уязвимостей они используют. Например, Linux и QEMU немедленно информируют общественность о несерьезных проблемах, в то время как серьезными проблемами занимаются те участники, которые есть в списке предварительного информирования Openwall.

Зеленые столбцы

Три зеленых столбца предоставляют информацию о некоторых ключевых аспектах степени информирования участников об уязвимостях по каждому проекту. Они отвечают на такие вопросы: обозначены ли известные уязвимости и эксплойты (CVE), сколько времени есть у поставщиков, чтобы пофиксить свою систему до того, как эта информация станет общедоступной, а также кто может получить информацию об уязвимостях в частном порядке через список предварительного информирования.

В этом разделе рассматривается одно из ключевых различий между Xen и Linux или QEMU: каждый, у кого есть продукт или услуга, построенная на Xen, будет проинформирован об уязвимости до того, как она станет общедоступной. Это значит, что они могут немедленно патчить свои системы или продукты. Поскольку Linux и QEMU раскрывают информацию по безопасности исключительно пользователям из списка дистрибутива Openwall, только очень небольшое число потребителей (обычно пользователи дистрибутивов Linux) получают привилегированную информацию, связанную с уязвимостями. Конечно, это также означает, что Xen Project должен бороться с уязвимостями, в том числе Linux и QEMU, в случае, если это влияет на наших пользователей. Если бы мы этого не делали, в зоне риска перед уязвимостью нулевого дня оказались бы некоторые из наших крупных пользователей, потому что мы бы не имели права информировать их об уязвимостях в частном порядке.

Текущая разработка

Поэтому, несмотря на шумиху в прессе, Xen действительно имеет солидную репутацию, когда дело доходит до безопасности. Фактически большинство обнаруженных уязвимостей Xen имеют оценку степени угрозы по CVSS от низкой до средней. За последние два года мы приняли много ужесточающих мер против уязвимостей, улучшили нашу кодовую базу. Кроме того, крупные поставщики облачных и продуктовых решений регулярно проводят проверки безопасности нашей кодовой базы. Также мы разработали новый тестовый фреймворк под названием XTF для поиска новых уязвимостей, и чтобы определить, внедряются ли существующие уязвимости в наш код повторно. В следующем разделе я продемонстрирую все дополнительные фичи и функциональные возможности, позволяющие Xen минимизировать влияние эксплойта.

Самодиагностика виртуальной машины (Virtual Machine Introspection)

Самодиагностика виртуальной машины (VMI) в Xen представляет новый подход к обнаружению угроз безопасности, позволяя контролировать память виртуальных машин вне виртуальной машины, практически исключая необходимость вмешательства. Если обнаружена подозрительная активность, такая как атака нулевого дня, ваше программное обеспечение для мониторинга может предпринять необходимые меры для ее устранения.

История

VMI была впервые разработана и интегрирована в Xen в 2007 году, а LibVMI позже была построена поверх нее как абстракция интерфейса. В то время считалось, что VMI слишком подвержена вмешательствам для того, чтобы использовать ее в коммерческих целях, но затем в 2014-2015 годах ее развитие возобновилось. Дело было в том, что Intel добавила аппаратную поддержку, которая сделала VMI достаточно эффективной, чтобы использоваться в облачных вычислениях. С тех пор участники сообщества Xen начали активно сотрудничать с целью улучшить VMI, включая переработку всей подсистемы, чтобы она могла быть использована в коммерческих целях.

Как работает VMI

Если вы хотите провести обнаружение вредоносных программ и угроз в типичной виртуализованной системе в облаке, вам необходимо запустить агент (например, антивирус, инспектор сетевых пакетов и т. д.) в каждой отдельной виртуальной машине. Первая проблема, связанная с этим процессом, заключается в том, что агенту необходимо будет просканировать память, хранилище и т. д., так что этот метод является довольно интрузивным. Вторая проблема заключается в том, что если в операционной системе, установленной на вашей виртуальной машине, есть эксплойт, то руткит или продвинутая постоянная угроза (APT) могут взять под контроль ваше ядро и обмануть агента, который будет считать, что система не заражена.

Рисунок 5. При использовании традиционной модели облачной безопасности руткит или APT могут отключить вашу систему, если в ОС, установленной на вашей виртуальной машине, есть эксплойт

С помощью VMI вы можете создать специальную виртуальную машину под названием «Приложение безопасности» (Security Appliance), которая содержит программное обеспечение безопасности и работает с интерфейсом VMI. Этот интерфейс настроен для мониторинга памяти нескольких виртуальных машин. Также возможно разбить большие системы для повышения масштабируемости. Например, на одном и том же хосте могут существовать несколько различных движков самодиагностики, контролирующих разные виртуальные машины.

Разумеется, мониторинг памяти всех этих виртуальных машин был бы крайне небезопасным и не может осуществляться в какой-либо облачной среде. Но действительно полезной функцией VMI является то, что вы можете создавать правила, которые обнаруживают конкретные техники атак, такие как «выполнение кода в куче». Это можно превратить в правило VMI, которое «будет уведомлять клиента, работающего в Security Appliance, когда код выполняется в областях памяти, связанных с кучей». Как только такое событие будет иметь место, устройство безопасности сможет предпринять меры по устранению нарушения.

Поскольку различные вирусы и вредоносные программы используют относительно небольшое количество техник прикрепления (например, переполнение буфера, выделение дополнительной памяти под кучу, инъекция кода, привязка API), мы можем создавать правила для VMI, которые бы позволяли обнаруживать эти техники. Это позволит защитить от новых классов вредоносных программ, даже не имея сведений о том, что они делают с системой, в отличие от традиционных инструментов проверки наличия вирусов и вредоносных программ, которые полагаются на проверку сигнатур вредоносных программ или следов артефактов, которые вредоносное ПО оставляет в системе.

Наша теория была испытана несколькими поставщиками, которые используют VMI в своих продуктах, в борьбе против многих уязвимостей нулевого дня, а также APT. Они доказали, что VMI действительно обнаруживает большое количество вредоносного ПО, не полагаясь на проверку сигнатур и другие традиционные методы обнаружения вредоносных программ. Поэтому вероятно, что VMI также будет обнаруживать новые и ранее неизвестные вредоносные программы.

Рисунок 6. Самодиагностика виртуальной машины — это метод для обнаружения конкретных методов атаки, который характеризуется низкой степенью вмешательства

VMI также работает за пределами VM, то есть мы можем избежать ранее упомянутого сценария, в котором руткиты или APT могут обмануть ваше программное обеспечение безопасности. Тем не менее, VMI не заменяет традиционные решения безопасности, потому что на данный момент она не может защитить против всех классов атак, не влияя на производительность. В будущем это станет возможным, но все же из соображений безопасности рекомендуется использовать VMI с традиционным программным обеспечением обнаружения вредоносных программ.

Коммерческие приложения

Решение VMI от Bitdefender: известное решение VMI, которое сразу же внедряет исправление в зараженную виртуальную машину, удаляет угрозу и очищает систему, а также предоставляет консоль, для того, чтобы системный администратор мог видеть, какие атаки произошли и как были устранены проблемы.
Решение VMI для Zentific: продукт похож на решение от Bitdefender, но с дополнительными интегрированными функциями для экспертного анализа и анализа данных (на которых специализируется компания).
AIS: стратегически важное исследование требований к технологиям виртуального пространства ВВС и Министерства обороны.

Дополнительные ресурсы

wiki.xenproject.org/wiki/Virtual_Machine_Introspection

Дезагрегация и модули безопасности Xen

Модули безопасности Xen (XSM) являются эквивалентом SELinux и дезагрегации. Эта функциональность была включена в кодовую базу Xen очень рано, но до недавнего времени, до того, как были значительно переработаны и дополнены компоненты, она особой популярностью не пользовалась.

Дезагрегация

Как я упоминал ранее, драйверы устройств в архитектуре Xen всегда запускаются в Dom0. На приведенной ниже диаграмме дезагрегации (рис. 7) мы удалили эти драйверы из Dom0 и поместили их в сетевой домен (Network Domain). Таким образом, мы получили сетевой драйвер (Network Driver), работающий в обычной виртуальной машине, не имеющей привилегий. Это означает, что Dom0 был удален из пути передачи данных для работы в сети. Если бы на сетевой драйвер была совершена атака, это повлияло бы только на сетевой домен. Поскольку в этом домене работает только драйвер устройства, эксплойт должен был бы перепрыгнуть через дополнительную границу VM, чтобы нанести какой-либо ущерб. Та же модель может применяться для доменов хранилищ. В Dom0 остается только функциональность, которая управляет всей информацией о конфигурации в системе Xen (например, QEMU или демон Xenstore). Опять же, вы можете просто запустить их в другом домене Xen, который создает то, что мы называем сильно дезагрегированной системой.

Рисунок 7. В дезагрегированной архитектуре драйверы устройств удаляются из Dom0 и помещаются в сетевой домен (Network Domain)

Рисунок 8. Эта же модель может применяться для доменов хранилищ. В Dom0 остается только функциональность, которая управляет всей информацией о конфигурации в системе Xen

Модули безопасности Xen

Еще одна действительно интересная функциональность — это то, что мы называем «модули безопасности Xen (Xen Security Modules — XSM)» или FLASK. XSM владеет всеми теми же инструментами, что и SELinux для разработки и проверки политик безопасности. Для каждого типа виртуальной машины мы определяем политику безопасности, которая контролирует, к какому набору гипервизоров (hypercall) или API разрешено обращаться данному типу виртуальной машины. Если одна из этих виртуальных машин вызывает API, на который у нее нет разрешения, вызов завершится с ошибкой. Представьте, что граница API — это стена, а эксплойт — это злоумышленник пытающийся перелезть через нее. Функциональность наподобие XSM как бы увеличивает высоту стены, что затрудняет ее преодоление.

Рисунок 9. Модули безопасности Xen увеличивают высоту пограничной стены API, что затрудняет задачу эксплойтов

Коммерческие приложения

Qubes: ОС, которая по своей архитектуре очень похожа на то, что сейчас используют компании на рынках автомобилестроения и встроенных систем.
OpenXT от BAE (оборонная компания) и AIS (охранная компания): платформа FOSS, построенная на Xen и OpenEmbedded для исследований в сфере безопасности, приложений безопасности и интеграции встроенных устройств. Несмотря на то, что она похожа на Qubes, этот проект с открытым исходным кодом, который является гибким и расширяемым, нацелен на более широкий ассортимент устройств.
Crucible Defense от Star Lab: платформа виртуализации для защиты технологий, улучшения противостояния кибератакам и целостности системы для аэрокосмических и оборонных систем.

Я хотел бы подробнее рассказать о Qubes OS, которая использует всю эту расширенную функциональность Xen, чтобы создать то, что мы называем «архитектура с защитой в глубину». На приведенной ниже диаграмме (рис. 10) показан пользовательский интерфейс операционной системы Qubes. В правом верхнем углу вы видите несколько виртуальных машин разных типов в диспетчере VM. Эти виртуальные машины используются в качестве защищенных песочниц для приложений и компонентов системы. Меню слева позволяет запускать различные приложения в отдельных песочницах.

Рисунок 10. Пользовательский интерфейс Qubes OS использует виртуальные машины в качестве защищенных песочниц для приложений и системных компонентов

На следующей диаграмме (рис. 11) компоненты Xen, используемые Qubes OS, накладываются поверх пользовательского интерфейса. Как вы можете видеть, гипервизор и Dom0 специально привязаны к диспетчеру VM и другим функциям интерфейса Qubes OS. Существует также сетевой домен (Network Domain) и домен брандмауэра (Firewall Domain), которые обеспечивают соблюдение всех ваших сетевых политик, а также домен USB, который изолирует вашу систему от любых угроз, которые могут быть вызваны взломанным USB-устройством.

Рисунок 11. Компоненты Xen, используемые операционной системой Qubes, накладываются поверх пользовательского интерфейса: гипервизор, Dom0, сетевой домен (Network Domain), домен брандмауэра (Firewall Domain), домен USB

Давайте рассмотрим пример использования. Как пользователь вы определяете несколько конкретных групп виртуальных машин для банковских операций, работы или личного использования. Всякий раз, когда вы запускаете приложение через интерфейс ОС Qubes, это конкретное приложение запускается в конкретной виртуальной машине. На системном уровне весь сетевой трафик маршрутизируется через брандмауэр и сетевые домены, что дает вам дополнительную защиту от сетевых угроз. Существует также загружаемая Tor VM, которая соединяет вашу сеть с Tor и перенаправляет весь сетевой трафик через сеть Tor, обеспечивая дополнительную анонимность. Когда вы запускаете веб-браузер и посещаете веб-сайт с вредоносной нагрузкой или открываете письмо с вредоносным ПО, оно влияет исключительно на работу виртуальной машины, в которой работает ваше приложение.

Дополнительные ресурсы

Xen для встроенных систем / автомобилестроения

В дополнение к богатому набору средств обеспечения безопасности Xen ускоряет разработку встроенных систем и продуктов автомобилестроения благодаря своим функциям планирования, задержки и поддержки устройств.

Планирование

Xen может устанавливать планировщик на разные процессоры, также вы можете выделить виртуальную машину специально для виртуального процессора без внедрения планировщика. В приведенной ниже таблице (рис. 12) рассматриваются два основных планировщика Xen: Credit и Credit 2. Они оба используются в облачных вычислениях, хотя Credit 2 является улучшенным вариантом Credit. Xen также поддерживает жесткий планировщик реального времени (ARINC 653) и мягкий планировщик реального времени (RTDS).

Рисунок 12. Xen поддерживает несколько разных планировщиков с различным набором свойств

Xilinx Xen, продукт, разработанный компанией, специализирующейся на военных и встроенных системах, дает возможность реализовать гибкость при участии Xen. Чипсет Xilinx содержит четыре A53 ядра ARM, которые могут быть виртуализированы, и четыре R5, которые не могут быть виртуализированы (у него также есть FPGA). Xilinx Xen содержит интересную функцию, называемую контейнерами Bare Metal Xen, которые позволяют помещать традиционное изображение ARM ELF в контейнер. Затем вы запускаете этот контейнер непосредственно в виртуальной машине, которую вы должны привязать к определенному виртуальному процессору. Эта настройка позволяет включать старый встроенный код в систему на основе Xen с помощью одного из этих контейнеров. Xilinx Xen также содержит драйверы и библиотеки для доступа к FPGA из виртуальной машины или контейнера Bare Metal.

Рисунок 13. Распределение Xilinx Xen демонстрирует некоторую гибкость с Xen

Задержка

Другой важной системной характеристикой для встроенной системы является задержка. В сообществе Xen существует теория, что за виртуальными прерываниями всегда следуют физические. Если прерывание происходит в виртуальном процессоре, оно затем перейдет и в физический, а потом передается дальше к другому виртуальному процессору. Например, если планировщик перемещает виртуальный процессор на другое ядро, прерывание автоматически переходит на второй виртуальный процессор. Затем, если прерывание появляется снова, оно автоматически перемещается на тот же второй виртуальный процессор. Это важно, потому что благодаря этому задержка обработки прерывания становится минимальной (около 2000 нс).

Поддержка устройств

Разработчики встроенных продуктов также нуждаются в поддержке различных устройств ввода/вывода. Xen обеспечивает поддержку многих устройств в своей базе кода (например, консоль, мышь, USB, совместное использование GPU), а в настоящее время разрабатывает поддержку для многих новых устройств. Разработка новых драйверов PV в Xen относительно проста (в зависимости от сложности устройства), и есть много примеров созданных драйверов PV (примеры доступны под лицензиями GPL v2 или BSD). Драйверы PV могут жить в пространстве ядра, а также в пространстве пользователя, которое применяется как к пользовательскому интерфейсу PV, так и к серверной части.

Коммерческие приложения

Встроенные системы

ARLX от Dornerworks: высокозащищенный продукт для приложений безопасности, который соответствует требованиям различных сертификатов безопасности.
Xilinx Xen Zynq от Dornerworks: полностью программируемый гетерогенный MPSoC, который обеспечивает масштабируемость 64-битного процессора, одновременно сочетая управление в реальном времени с мягкими и жесткими движками для графики, видео, временных диаграммы и обработки пакетов.
NXP Xen от Dornerworks: позволяет разработчикам запускать несколько операционных систем на NXP i.MX 8.
Crucible и Crucible Defense от Star Lab: аналогичные продукты для ARLX, но с использованием MiniOS вместо Linux в Dom0.
FreeRTOS port от Galois: минимальная ОС для микроконтроллеров, которая работает, как гость Xen на ARM Cortex A15.
Haskell Lightweight VM от Galois: позволяет разработчикам запускать программы Haskell на «голом» (виртуальном) железе внутри домена Xen без хостовой операционной системы.

Автомобилестроение

Nautilus Platform от GlobalLogic: набор автомобильных акселераторов решений для информационно-развлекательного ПО (IVI), которые включают в себя архитектурные концепции, модифицированный дистрибутив ОС Android и улучшенный пользовательский интерфейс.
Cloud Fusion Platform от EPAM: автомобильная платформа с сетевыми возможностями, которая позволяет функциональности автомобиля подключаться к облаку.
XenGT от LG: планирование графиков в реальном времени для автомобильных встроенных систем.
Решение для защиты виртуальных систем от Perseus: отделяет исходный домен автомобиля с сетевыми возможностями от других доменов и защищает ОС автомобиля от вредоносных программ и DDoS-атак.

Давайте подробнее рассмотрим продукт GlobalLogic Nautilus, который будет внедрен в транспортные средства, запланированные к выпуску уже в первом квартале 2018 года. Nautilus поддерживает много различных аппаратных платформ, операционных систем и устройств ввода/вывода. Как вы можете видеть на архитектурной схеме ниже (рис. 14), Nautilus использует Xen для управления несколькими операционными системами на одном SoC, чтобы транспортные средства могли запускать настраиваемое информационно-развлекательное программное обеспечение без риска повлиять на критически важное программное обеспечение автомобиля. Xen позволяет производителям автомобилей и разработчикам программного обеспечения достичь лучших результатов без ущерба для обеих систем, и все это при минимальных требованиях к аппаратному обеспечению.

Рисунок 14. Платформа Nautilus от GlobalLogic использует Xen для запуска нескольких ОС на одном SoC, безопасно отделяя информационно-развлекательное программное обеспечение (IVI) от критически важного ПО автомобиля

Вывод

Итак, зачем использовать Xen для виртуализации? Xen является гибким и надежным, предлагает инновационные функции и может быть сертифицирован на соответствие различным требованиям безопасности. Сообщество Xen также чрезвычайно успешно и активно развивается, и за последние несколько лет количество вкладов в разработку значительно увеличилось. 48 % вкладов пришло от Citrix в 2015 году, но всего через год эта цифра сократилась до 33 %, поскольку все больше и больше вкладов поступало также от разных компаний, занимающихся встроенными системами, и экосистемы ARM. Таким образом, мы видим, что сообщество Xen постоянно растет и становится все более разнообразным. Благодаря этому мы становимся участниками разработки потрясающего нового функционала и появления новых вариантов использования.

Рисунок 15. Сообщество Xen активное и разнообразное. За последние несколько лет его вклад вырос в десять раз

От редакции: если у вас есть вопросы к Ларсу, оставляйте их в комментариях на английском языке.