Встроенный гипервизор - Embedded hypervisor

An встроенный гипервизор это гипервизор который поддерживает требования встроенные системы.

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

Типичные атрибуты встроенной виртуализации включают эффективность, безопасность, связь, изоляцию и возможности реального времени.^[1]

Задний план

Виртуализация программного обеспечения была главной темой в корпоративном пространстве с конца 1960-х годов, но только с начала 2000-х годов ее использование появилось во встроенных системах. Использование виртуализации и ее реализация в виде гипервизора во встроенных системах сильно отличаются от корпоративных приложений. Эффективная реализация встроенного гипервизора должна решать ряд проблем, специфичных для таких приложений. Эти проблемы включают высокоинтегрированный характер встроенных систем, потребность в изолированных функциональных блоках внутри системы для быстрой связи, потребность в детерминированной производительности в реальном времени, целевая среда с ограниченными ресурсами и широкий спектр требований безопасности и надежности.

Гипервизор

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

Классификация

Гипервизоры обычно классифицируются как тип 1 или тип 2, в зависимости от того, работает ли гипервизор исключительно в режим супервизора либо привилегированный режим (тип 1), либо сам размещается в операционной системе как обычное приложение (тип 2).

Гипервизоры типа 1 управляют ключевыми системными ресурсами, необходимыми для поддержания контроля над виртуальными машинами, и обеспечивают минимальное надежная вычислительная база (УТС). Гипервизоры типа 2 обычно запускаются как приложение в операционной системе более общего назначения, полагаясь на службы ОС для управления системными ресурсами. В настоящее время расширения ядра часто загружаются, чтобы воспользоваться преимуществами оборудования с поддержкой виртуализации.

Встроенный гипервизор

Встроенный гипервизор чаще всего представляет собой гипервизор типа 1, который поддерживает требования встроенные системы развитие. См. Ссылки^[2] и^[3] для более подробного обсуждения.

Эти требования кратко изложены ниже.

• Небольшой быстрый гипервизор с поддержкой нескольких изолированных виртуальных машин;
• Поддержка легкой, но безопасной инкапсуляции компонентов подсистемы среднего размера, которые сильно взаимодействуют;
• Связь с высокой пропускной способностью и малой задержкой между компонентами системы в соответствии с настраиваемой общесистемной политикой безопасности;
• Минимальное влияние на системные ресурсы и поддержка гарантий задержки в реальном времени;
• Возможность реализовать политику планирования между виртуальными машинами и обеспечить поддержку компонентов системы в реальном времени;

Реализация

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

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

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

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

Дизайн гипервизора

Реализации для приложений встраиваемых систем чаще всего основывались на небольших микроядро и ядро разделения проекты, со встроенной виртуализацией как неотъемлемой частью. Это было введено с PikeOS в 2005 году.^[4] Примеры этих подходов были разработаны такими компаниями, как Открытые лаборатории ядра (микроядро, за которым следует разделительное ядро) и LynuxWorks (разделительное ядро). VirtualLogix похоже, занимает позицию, что подход, основанный на Виртуальная машина Монитор (VMM) будет еще меньше и эффективнее. Этот вопрос является предметом продолжающихся дискуссий.^[5][6][7] Однако главный вопрос одинаков для всех сторон обсуждения - скорость и размер реализации (для заданного уровня функциональности) имеют большое значение. Например: «... гипервизоры для встраиваемых систем должны поддерживать работу в реальном времени, а также ограничивать ресурсы».

Требования к ресурсам

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

С помощью небольшого TCB встроенного гипервизора типа 1 систему можно сделать очень безопасной и надежной.^[8] Стандартные методы разработки программного обеспечения, такие как проверки кода и систематическое тестирование, могут использоваться для уменьшения количества ошибок в такой небольшой кодовой базе до крошечной доли дефектов, которые должны ожидаться для комбинации гипервизора и гостевой ОС, которая может быть Всего 100 000–300 000 строк.^[9]

Связь с ВМ

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

An межпроцессного взаимодействия (IPC) механизм может использоваться для обеспечения этих функций, а также для вызова всех системных служб и реализован таким образом, чтобы гарантировать поддержание желаемого уровня изоляции виртуальной машины. Кроме того, из-за значительного влияния на производительность системы такой механизм IPC должен быть оптимизирован для минимальной задержки.^[10]

Требования к оборудованию

Встроенный гипервизор должен полностью контролировать системные ресурсы, включая доступ к памяти, чтобы программное обеспечение не могло вырваться из виртуальной машины. Следовательно, гипервизору требуется цель ЦПУ предоставлять управление памятью поддержка (обычно с использованием MMU ). Многие встроенные процессоры, включая такие как РУКА, MIPS и PowerPC последовали за поставщиками настольных ПК и серверных микросхем, добавив аппаратную поддержку виртуализации. Однако все еще существует значительная часть встроенных процессоров, которые не обеспечивают такой поддержки, а гипервизор поддерживает паравиртуализация требуется.

Процессоры ARM примечательны тем, что большинство процессоров их прикладного класса поддерживают технологию ARM TrustZone, которая обеспечивает аппаратную поддержку одной привилегированной и одной непривилегированной виртуальной машины. Обычно минимальная операционная система Trusted Execution Environment (TEE) работает в Безопасном мире, а собственное ядро ​​- в Небезопасном мире.

Сценарии использования

Вот некоторые из наиболее распространенных вариантов использования встроенного гипервизора:^[11][12]

1. Независимость от ОС

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

2. Поддержка нескольких операционных систем на одном процессоре.

Обычно это используется для запуска операционная система реального времени (RTOS) для низкоуровневых функций реального времени (таких как стек связи) при одновременном запуске ОС общего назначения, (GPOS) любить Linux или Windows, для поддержки пользовательских приложений, таких как веб-браузер или календарь. Целью может быть обновление существующей конструкции без дополнительной сложности второго процессора или просто минимизация ведомость материалов (БМ).

3. Безопасность системы

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

4. Надежность системы

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

5. Динамическое обновление системного ПО.

Программное обеспечение или приложения подсистемы могут быть безопасно обновлены и проверены на целостность путем загрузки в защищенную виртуальную машину перед «запуском» в исполняющую систему. Даже если этот процесс затем завершится неудачно, система может вернуться в свое прежнее состояние, перезапустив исходную программную подсистему / приложение без остановки работы системы.

6. Повторное использование старого кода.

Виртуализация позволяет использовать унаследованный встроенный код со средой ОС, в которой он был разработан и проверен, при этом позволяя разработчику использовать другую среду ОС в отдельной виртуальной машине для новых служб и приложений. Унаследованный встроенный код, написанный для конкретной конфигурации системы, может брать на себя исключительное управление всеми системными ресурсами памяти, ввода-вывода и процессора. Эту кодовую базу можно повторно использовать без изменений в альтернативных системных конфигурациях ввода-вывода и памяти за счет использования виртуальной машины для представления карты ресурсов и функций, которые согласуются с исходной конфигурацией системы, эффективно отделяя унаследованный код от особенности новой или измененной конструкции оборудования.

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

Даже без доступа к исходному тексту унаследованный двоичный код может выполняться в системах, работающих на процессорах с поддержкой аппаратной виртуализации, таких как AMD-V, Intel VT технологии и новейшие РУКА процессоры с поддержкой виртуализации.^[13] Унаследованный двоичный код может выполняться в виртуальной машине без изменений, при этом все сопоставления ресурсов обрабатываются встроенным гипервизором, если аппаратное обеспечение системы обеспечивает эквивалентную функциональность.

7. Защита интеллектуальной собственности

Ценный запатентованный IP может потребоваться защита от кражи или неправомерного использования, когда встроенная платформа отправляется для дальнейшей разработки (например) OEM покупатель. Встроенный гипервизор позволяет ограничить доступ других компонентов программного обеспечения системы к определенной части системы, содержащей IP-адрес, который необходимо защитить.

8. Разделение лицензий на программное обеспечение

Программный IP, работающий по одной схеме лицензирования, может быть отделен от другого программного IP, работающего по другой схеме. Например, встроенный гипервизор может обеспечить изолированную среду выполнения для проприетарного программного обеспечения, совместно использующего процессор с программным обеспечением с открытым исходным кодом, подпадающим под действие GPL.^[14]

9. Миграция приложений с одноядерных систем на многоядерные.

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

Коммерческие продукты

• Тигель компании Star Lab Corp. ^[15]
• Межоперационный гипервизор - позволяет приложениям запускаться на одной платформе ОС от MapuSoft Technologies, Inc.
• OKL4 Hypervisor - поддерживает интеллектуальные подключенные устройства на базе ARM (встроенные, мобильные). Используется в приложениях, требующих защиты и безопасности. Коммерчески поддерживается Cog Systems.

использованная литература

1. [1] Виртуализация для встроенных систем
2. [2] Роль виртуализации во встроенных системах
3. [3] В архиве 2008-10-10 на Wayback Machine Виртуализация и гипервизоры помогают в разработке встраиваемых систем
4. [4] Пять лет переосмысления дизайна встроенных систем
5. [5] Маленькие ядра против мониторов виртуальных машин
6. [6] Правильно ли выполнены микроядра мониторов виртуальных машин?
7. [7] В архиве 2008-05-11 на Wayback Machine (Ответ на вопрос) Правильно ли выполнены микроядра мониторов виртуальных машин?
8. [8] Насколько безопасна ваша система?
9. [9] Надежные вычислительные системы
10. [10] Улучшение IPC за счет дизайна ядра
11. Хайзер, Гернот (27 ноября 2007 г.). Виртуализация для встроенных систем (PDF) (Технический отчет). С. 10–16.
12. Штробль, Мариус (2013). Виртуализация для надежных встроенных систем. Мюнхен: GRIN Publishing GmbH. С. 11–17. ISBN  978-3-656-49071-5.
13. [11] В архиве 2013-05-03 в Wayback Machine Расширения виртуализации ARM
14. [12] GPL FAQ
15. Crucible - безопасная встроенная виртуализация