Vmbus power device что за устройство
Устройство VMBus не загружается на виртуальную машину, которая работает на компьютере с Hyper-V установленной
В этой статье помогают устранить проблему, из-за которой устройство VMBus не загружается на виртуальную машину, созданную с помощью виртуального сервера 2005 или виртуального ПК 2007.
Применяется к: Windows 10 — все выпуски, Windows Server 2012 R2
Исходный номер КБ: 954282
Симптомы
Рассмотрим следующий сценарий.
В этом сценарии устройство интеграции VMBus не загружается. При открываемом диспетчере устройств на виртуальной машине рядом с VMBus появляется желтый треугольник с восклицательный точкой. Когда вы дважды щелкните VMBus, диалоговое окно VMBus Properties отображает одно из следующих сообщений:
Это устройство не может найти достаточно бесплатных ресурсов, которые он может использовать. (Код 12).
Это устройство не может запуститься. (Код 10).
Причина
Эта проблема возникает из-за того, что уровень аппаратной абстракции (HAL) не обновляется автоматически.
Когда виртуальная машина создается с помощью виртуального сервера или виртуального компьютера, используется HAL Advanced Configuration and Power Interface (ACPI). Службам интеграции для правильной загрузки устройства VMBus требуется контроллер прерывания с расширенными программируемыми программами (APIC).
Решение
Чтобы устранить эту проблему, выполните следующие действия:
Вы можете очистить шажок Detect HAL, выбранный на шаге 4. Если выбрано поле Detect HAL, для запуска виртуальной машины требуется немного больше времени.
Дополнительная информация
Дополнительные сведения см. в Hyper-V технологии.
Исследуем внутренние механизмы работы Hyper-V
Если бы работа хакера, а точнее программиста-исследователя происходила так, как это показано в классических фильмах: пришел, постучал по клавишам, на экране все замелькало зеленым, пароли взломались, а деньги внезапно переехали из пункта А в пункт В, — то жить было бы однозначно проще и веселее. Но в действительности любому серьезному хаку всегда предшествует основательная и скучная аналитическая работа. Вот ею мы и займемся, а результаты выкатим на твой суд в виде цикла из двух статей. Убедись, что у тебя есть достаточный запас пива и сигарет, — прочтение таких материалов опасно для неподготовленного мозга :).
Обнаружение бага, получившего впоследствии номер MS13-092 (ошибка в компоненте Hyper-V Windows Server 2012, позволяющая отправить гипервизор в BSOD из гостевой ОС или выполнить произвольный код в других гостевых ОС, запущенных на уязвимом хост-сервере), стало очень неприятным сюрпризом для инженеров Microsoft. До этого в течение почти трех лет никто не обнаруживал уязвимости в Hyper-V. До нее была только MS10-102, которую нашли в конце 2010 года. За эти четыре года популярность облачных сервисов сильно возросла, и исследователи проявляют все больший интерес к безопасности гипервизоров, лежащих в основе облачных систем. Однако количество публично доступных работ крайне невелико: исследователи неохотно тратят свое время на изучение таких сложных и плохо документированных архитектурных решений. В этой статье не рассказано о конкретных уязвимостях гипервизора, но она должна пролить свет на работу некоторых внутренних механизмов Hyper-V и тем самым частично упростить будущие исследования.
Перед прочтением статьи рекомендуется ознакомиться с отчетом ERNW, материалом «Hyper-V debugging for beginners», а также с официальным документом Hypervisor TLFS.
VMBus
Во время написания статьи в качестве Hyper-V-сервера и гостевой ОС использовалась Windows Server 2012 R2 Update 1 (тип машины — Generation 1), но для отражения некоторых особенностей работы шины были использованы и другие версии операционных систем Windows, что явно будет указано в статье. Тестовую среду лучше разворачивать в VMware Workstation 2014 July TechPreview или поздних, поскольку в более ранних версиях баг в Workstation не позволяет выполнять отладку виртуальных машин по сети (либо необходимо в конфигурации виртуальной машины принудительно указывать использование UEFI). Также в дальнейшем будет подразумеваться, что стенд развернут на аппаратной платформе Intel и функции гипервизора реализованы в hvix64.exe.
Термины и определения
О Vmbus
Если говорить кратко, то VMBus — это технология взаимодействия гостевых операционных систем и root ОС. Соответственно, как в гостевой, так и в root ОС присутствуют компоненты, реализующие это взаимодействие через интерфейсы, предоставляемые гипервизором и описанные в TLFS 4.0. Microsoft разрабатывает гостевые компоненты для операционных систем семейства Linux, которые интегрированы в ядро Linux и выложены отдельно на GitHub: github.com/LIS/LIS3.5.
Начиная с Windows Server 2008 в ядре Windows появились функции, оптимизирующие работу операционной системы в виртуальной среде Hyper-V. Для сравнения, в ядре Windows Server 2008 (x64) реализовано всего 25 функций с префиксом Hvl, который идентифицирует их принадлежность к библиотеке интеграции с гипервизором, в Windows Server 2012 R2 уже присутствует 109 Hvl-функций.
Рассмотрим, каким же образом компоненты шины VMBus взаимодействуют с гипервизором, root ОС и гостевой ОС. Сперва заглянем в исходные коды LIS и увидим, что VMBus — это устройство, поддерживающее ACPI. ACPI позволяет стандартизировать аппаратную платформу для различных операционных систем и реализован в Hyper-V (как, впрочем, и в других популярных платформах виртуализации), что позволяет использовать стандартные утилиты для получения необходимой для исследования информации.
ACPI-устройства можно просмотреть при помощи утилиты ACPI tool, входящей в старую версию AIDA64 (в более поздних она была удалена). С ее помощью в _SB.PCI0.SBRG обнаруживаются два устройства: VMB8 и VMBS (см. рис. 1).
Рис. 1. Устройства VMB8 и VMBS
Сдампим ACPI DSDT (Differentiated System Description Table) таблицу, которая содержит информацию о периферийных устройствах и дополнительных функциях аппаратной платформы, с помощью той же утилиты ACPI Tool и декомпилируем AML-дизассемблером в ASL. Получим дамп, показанный на рис. 2.
Рис. 2. Дамп ASL
Поверхностное чтение Advanced Configuration and Power Interface Specification 5.0 дало понять, что в случае, если гостевая ОС — Windows 6.2 и выше, то будет задействовано устройство VMB8, в противном случае — VMBS. Единственное отличие этих устройств — объект _UID (Unique ID), который присутствует в VMB8. Если верить спецификации на ACPI, то присутствие этого объекта в таблице опционально и требуется только в том случае, если устройство не может иными способами предоставить операционной системе постоянный уникальный идентификатор устройства. Также стали известны ресурсы, которое использует устройство, — прерывания 5 и 7.
Для сравнения: в виртуальной машине типа Generation 2 присутствует только устройство VMBS, размещенное в _SB_.VMOD.VMBS (но с объектом _UID), которое использует только прерывание 5 (см. рис. 3).
Рис. 3. Часть ASL дампа Gen2
Обработка прерываний в виртуальной среде
В Windows обработку прерываний выполняют процедуры, зарегистрированные в таблице диспетчеризации прерываний (IDT). Между обнаруженными нами в ACPI DSDT IRQ 5 и 7 и обработчиками в IDT прямой связи нет, и для того, чтобы сопоставить прерыванию его обработчик, Windows использует арбитр прерываний (вообще, существует несколько классов арбитров, помимо IRQ, — DMA, I/O, memory).
Все об арбитрах в блоге MSDN
Вывод команды показывает, что для IRQ 7 адрес обработчика будет находиться в 0x71 элементе IDT, для IRQ 5 — в 0x81. Генерация номеров обработчиков прерываний происходит в функции acpi!ProcessorReserveIdtEntries на этапе построения дерева устройств PnP-менеджером, когда функциональный драйвер устройства еще не загружен. Регистрация ISR в IDT происходит уже на более поздних этапах, например при выполнении процедуры IoConnectInterrupt самим драйвером устройства. Однако, просмотрев элементы IDT, мы увидим, что ISR для прерываний 0x71 и 0x81 не зарегистрированы:
В Windows Server 2012 R2 Gen2 для IRQ 5 был сопоставлен 0x90-й элемент IDT.
Однако, как показывает отладчик, ISR-процедура для вектора 0x90 также не определена:
В Windows 8.1 x86 мы видим несколько иную картину:
При этом для прерывания с номером 0x81 определена ISR-процедура vmbus!XPartPncIsr:
s3cap — вспомогательный драйвер для работы с эмулируемой Hyper-V видеокартой S3 Trio.
Vmbus interrupt object
Таким образом, ISR vmbus!XPartPncIsr регистрируется в IDT только в Windows 8.1 x86 (предположительно, в других x86 операционных системах, которые Microsoft поддерживает в качестве гостевых ОС для Hyper-V, используется такой же метод). Процедура vmbus!XPartPncIsr используется для обработки прерываний, генерируемых гипервизором.
В x64-битных системах, начиная с Windows 8\Windows Server 2012, интеграция с гипервизором реализована несколько иначе. В IDT операционных систем были добавлены обработчики системных прерываний, генерируемых гипервизором. Кратко рассмотрим, каким образом формируется IDT на этапе загрузки Windows.
После инициализации загрузчика Windows winload.efi IDT выглядит следующим образом (вывод скрипта на pykd в точке останова WinDBG в winload.efi при загрузке операционной системы с параметром /bootdebug):
Затем во время выполнения winload!OslArchTransferToKernel IDT обнуляется, управление передается ядру Windows, где в функции nt!KiInitializeBootStructures IDT инициализируется значениями из таблицы KiInterruptInitTable:
Соответственно, обработчики системных прерываний 0x30–0x34 после завершения инициализации будут выглядеть следующим образом:
Виртуальную машину второго поколения в Hyper-V можно создать только на базе ОС, содержащих в ядре пять описанных выше дополнительных обработчиков. В целях генерации прерываний Intel представляет аппаратную функцию virtual interrupt delivery, однако Hyper-V не использует указанную возможность для передачи управления на эти обработчики. Вместо этого в гипервизоре происходит активация бита, соответствующего номеру вектора, в специальной области памяти с помощью инструкции вида lock bts [rcx+598h], rax, где rax — номер вектора прерывания (0x30–0x32), так что, возможно, разработчики Hyper-V сочли вариант с регистрацией процедуры vmbus!XPartPncIsr в качестве обработчика менее производительным решением, чем вариант генерации прерываний посредством виртуализации APIC на основе данных в виртуальных регистрах SINTx.
Указанные обработчики регистрируются в IDT даже в том случае, если операционная система работает вне среды Hyper-V. Каждый обработчик вызывает HvlRouteInterrupt, передавая индекс в качестве параметра (см. рис. 6).
Рис. 6. Дополнительные системные обработчики ядра Windows
HvlRouteInterrupt выглядит следующим образом (рис. 7).
Рис. 7. HvlRouteInterrupt
Эта функция вызывает обработчик из массива указателей HvlpInterruptCallback в зависимости от значения индекса. Этот массив в root ОС выглядит так:
XPartEnlightenedIsr по индексу, переданному из KiVmbusInterruptX, добавляет в DPC-очередь одну из двух возможных функций из массива DPC-структур в vmbusr: vmbusr!ParentInterruptDpc или же vmbusr!ParentRingInterruptDpc (рис. 8).
Рис. 8. DPC-объекты
Количество структур DPC в массиве определяется функцией vmbusr!XPartPncPostInterruptsEnabledParent и зависит от количества логических процессоров в root ОС. Для каждого логического процессора добавляется DPC c vmbusr!ParentInterruptDpc и vmbusr!ParentRingInterruptDpc. Функция vmbusr!ParentRingInterruptDpc определяет адрес DPC-процедуры для nt!KeInsertQueueDpc исходя из того, на каком процессоре выполняется в текущий момент.
В гостевой ОС VMBus регистрирует в массиве HvlpInterruptCallback только один обработчик:
Массив HvlpInterruptCallback заполняется с помощью экспортируемой ядром функции nt!HvlRegisterInterruptCallback. Обработчик WinHvOnInterrupt регистрируется при загрузке драйвера winhvr.sys (winhvr!WinHvpInitialize-> winhvr!WinHvReportPresentHypervisor-> winhvr!WinHvpConnectToHypervisor-> nt!HvlRegisterInterruptCallback)/
Остальные четыре обработчика регистрируются драйвером vmbusr.sys при его загрузке PnP-менеджером (vmbusr!RootDevicePrepareHardwareParent-> nt!HvlRegisterInterruptCallback).
!apic в root ОС
!apic в гостевой ОС
Конфигурирование регистров SINT0 и SINT1 выполняется функцией nt!HvlEnlightenProcessor путем записи параметров в MSR-регистры 40000090h и 40000091h соответственно. SINT4 и SINT5 конфигурируются драйвером vmbusr.sys: vmbusr!XPartPncPostInterruptsEnabledParent-> winhvr!WinHvSetSint->winhvr!WinHvSetSintOnCurrentProcessor. SINT2 в гостевой ОС конфигурируется драйвером vmbus.sys в функции winhv!WinHvSetSintOnCurrentProcessor.
В каждом SINTx присутствует 8-битное поле Vector. От значения этого поля зависит то, какой процедуре обработки прерываний будет передано управление при выполнении гипервызовов, в параметрах которых задается PortID (HvSignalEvent, HvPostMessage).
SINTx может быть задан неявно (например, для сообщения перехвата всегда будет контролироваться регистром SINT0 и соответственно располагаться в первом элементе страница SIM), явно (для сообщений таймера) или же указан в параметрах порта, созданного с помощью гипервызова HvCreatePort. Одним из параметров является PortTypeInfo. Если тип порта — HvPortTypeMessage или HvPortTypeEvent, то в параметре PortTypeInfo присутствует TargetSint, содержащий номер SINT, к которому будет привязан порт и значение которого может быть в пределах от 1 до 15 (SINT0 зарезервирован для сообщений от гипервизора и не может быть указан в качестве TargetSint при создании порта).
Анализ значений активных регистров SINT в root ОС показывает, что в работе будут задействованы только три обработчика системных прерываний (KiHvInterrupt, KiVmbusInterrupt0, KiVmbusInterrupt1) из пяти. В каких целях в ядро были добавлены системные обработчики KiVmbusInterrupt2 и KiVmbusInterrupt3, обнаружить не удалось. Возможно, они будут нужны на серверах с большим количеством логических процессоров (например, 64), но, к сожалению, в тестовой среде это проверить не удалось. Также по значениям регистров SINTx видно, что обработчик nt!KiHvInterrupt (вектор 30) будет вызываться как при генерации прерываний от гипервизора, так и через порты, созданные с параметром TargetSint, равным 1.
Windows и TLFS
Для примера рассмотрим параметры портов, создаваемых при активации каждого из сервисов гостевых компонентов интеграции Hyper-V. На рис. 11 приведены характеристики портов, создаваемых для работы служб интеграции (по одному порту для каждого компонента).
Рис. 11. Порты служб интеграции
Взаимодействие root ОС и гостевой ОС в ходе работы компонентов Integration Services происходит через 5-й элемент массива SIEF, то есть обработчиком в root ОС будет KiVmbusInterrupt1.
Номер каждого следующего создаваемого порта равен предыдущему, увеличенному на 1. То есть если отключить все сервисы интеграции и затем включить их повторно, то номера портов, создаваемых для этих сервисов, будут находиться в диапазоне от 0x22 до 0x27.
Параметры порта можно увидеть, если подключиться отладчиком непосредственно к гипервизору и отслеживать данные, передаваемые обработчику гипервызова HvCreatePort, или же подключиться отладчиком к ядру и отслеживать параметры функции WinHvCreatePort в драйвере winhvr.sys.
Остальные порты, которые создаются при включении гостевой ОС (количество портов зависит от конфигурации гостевой операционной системы), представлены на рис. 12. Нумерация приведена в порядке создания портов при включении виртуальной машины Windows Server 2012 R2 с конфигурацией оборудования по умолчанию.
Рис. 12. Порты, создаваемые при запуске виртуальной машины00000000000000.
Важно отметить тот факт, что нулевой слот SIM как в гостевой, так и в родительской ОС зарезервирован для передачи сообщений от гипервизора. Формат таких сообщений документирован в TLFS. При передаче данных через оставшиеся слоты используется иной формат данных. Сообщения VMBus не документированы, но необходимая информация для работы с ними присутствует в исходных кодах LIS.
Некоторая информация об обработке VMBus-сообщений драйвером vmbusr.sys (см. рис. 13). Такие сообщения в root ОС обрабатывает функция vmbusr!ChReceiveChannelMessage, которая анализирует содержимое 4-го слота SIM и определяет код VMBus-сообщения. Если он равен 0 (CHANNELMSG_INVALID) или же больше 0x12, то функция возвращает ошибку и 0xC000000D (STATUS_INVALID_PARAMETER). В противном случае функция обрабатывает переданное гостевой или root ОС сообщение. Например, при включении компонента Guest Services root ОС отправляет гостевой ОС сообщение CHANNELMSG_OFFERCHANNEL, в ответ гостевая ОС отправляет сообщение CHANNELMSG_GPADL_HEADER, затем root ОС отправляет CHANNELMSG_GPADL_CREATED, получает обратно сообщение CHANNELMSG_OPENCHANNEL и в завершение диалога отправляет гостевой ОС сообщение CHANNELMSG_OPENCHANNEL_RESULT с кодом результата выполнения операции по созданию канала. Стоит обратить внимание на то, что перед обработкой каждого валидного сообщения функция ChReceiveChannelMessage выполняет проверку переданного сообщения (ChpValidateMessage), в частности на предмет того, кто является отправителем (root ОС или гостевая ОС), минимального размера тела сообщения. Для каждого типа сообщения заданы свои условия проверки. На рис. 13 отмечены те сообщения, которые будут обрабатываться в случае их отправки гостевой ОС (могут быть интересны, например, для создания фаззера).
Рис. 13. VMBus-сообщения, обрабатываемые драйвером vmbusr.sys
Для того чтобы понять, какими же сообщениями обмениваются root ОС и гостевая ОС, мы напишем драйвер, который заменяет адреса обработчиков из массива HvlpInterruptCallback в root ОС на свои собственные обработчики. Но об этом — в следующей статье.
Заключение
В первой части статьи были проанализированы изменения ядра операционной системы, внесенные Microsoft для оптимизации работы в виртуальной среде, влияющие на работу VMBus. В этом номере ][ мы разобрали теорию, а в следующем будет опубликована практическая часть исследования, поэтому запасайся терпением.
Впервые опубликовано в журнале «Хакер» от 11/2014.
Второе поколение виртуальных машин в Windows Server 2012 R2
Сегодня я хотел бы подробнее остановиться на одной из новых возможностей Hyper-V в Windows Server 2012 R2, упомянутой мною в обзорном посте, а именно, обсудить второе поколение виртуальных машин (ВМ). Тема становится особенно актуальной с доступностью RTM Windows Server 2012 R2 для подписчиков TechNet и MSDN и скорым выпуском финальной версии System Center 2012 R2
Почему появилось второе поколение ВМ?
С выходом Windows Server 2012 R2 в Hyper-V появилось возможность создавать ВМ двух разных типов или двух разных поколений (Generation 1 и Generation 2). ВМ первого поколения представляют собой виртуальные машины, хорошо известные по предыдущим версиям Hyper-V. Все, что вы привыкли видеть в настройках ВМ, плюс ряд новых настроек, вы увидите в машинах первого поколения. Они никуда не делись, вы можете и дальше спокойно их использовать.
Но помимо этого вы можете теперь создавать ВМ второго поколения. Это поколение отражает изменения, которые произошли и продолжают происходить как в архитектуре ОС, так и в аппаратном обеспечении современных компьютеров. На рубеже Windows 2000, Windows XP, Windows Server 2003 операционные системы проектировались без учета технологий виртуализации, тогда еще только набиравших обороты. Чтобы нормально запустить такие ОС внутри виртуальной машины необходимо было создать для них иллюзию запуска на физическом компьютере. Как следствие, приходилось эмулировать различное оборудование, как то: BIOS, контроллер прерываний, IDE-контроллер, стандартные порты ввода-вывода и пр. Вы легко увидите перечень эмулируемых устройств, если загляните в Device Manager на ВМ первого поколения.
Эмуляция, с одной стороны, приводит к дополнительным накладным расходам, прежде всего, к лишним тактам процессора, с другой стороны, каждое эмулируемой устройство – дополнительный довольно сложный код, потенциально расширяющий поверхность для атак.
С течением времени ОС стали проектироваться с учетом того, что система может, или даже скорее всего будет работать в виртуальной среде. Такая ОС «знает», что запускается внутри ВМ и, как на этапе загрузки, так и в ходе своей работы, опирается на ресурсы, предоставляемые родительским разделом (хостовой ОС). Иными словами, ОС уже при старте общается с гипервизором через шину VMBus, а не рассчитывает обнаружить контроллер прерываний или чипсет определенного типа. Следовательно, для таких ОС можно отказаться от унаследованных эмулируемых устройств и повысить производительность ВМ. Действительно, в Deviсe Manager ВМ второго поколения картина будет иной.
В чем преимущества ВМ второго поколения?
Отказ от эмуляции устаревших устройств изменяет «начинку» ВМ второго поколения. В свойствах таких ВМ вы увидите примерно следующее:
В качестве иллюстрации я провел следующий эксперимент: создал две ВМ, первого и второго поколения соответственно, обеим ВМ выделил одинаковое количество оперативной памяти и виртуальных процессоров и одновременно запустил установку Windows Server 2012 R2 внутри созданных ВМ с одного и того же ISO-образа. Вот так выглядела картина в начальной фазе установки (ВМ второго поколения внизу):
И вот такую разницу можно было наблюдать позже:
Таким образом, при развертывании ВМ, а также при старте ВМ, что, например, особенно важно в сценариях VDI, разница в производительности ВМ второго поколения может достигать 50% и более.
Особенности использования ВМ второго поколения
Необходимо помнить несколько принципиальных моментов, относящихся к эксплуатации ВМ второго поколения.
Вы можете создать ВМ второго поколения в консоли Hyper-V,
либо с помощью командлета PowerShell New-VM, указав ключ –Generation 2.
При этом надо иметь в виду, что поколение указывается только на этапе создания ВМ. В дальнейшем конвертировать ВМ из одного поколения в другое невозможно как раз в силу того, что в одном случае используется BIOS, в другом – UEFI.
Последний аспект, который хотелось бы отметить, связан с управлением. Управление хостами с Windows Server 2012 R2 возможно с помощью System Center 2012 R2 Virtual Machine Manager. В доступной сейчас preview-версии System Center 2012 R2 поддержка второго поколения ВМ отсутствует. Но в RTM-версии System Center 2012 R2 (а она уже не за горами) эта поддержка будет добавлена.
Итак, новое поколение ВМ в Windows Server 2012 R2 лишено устаревших эмулируемых устройств, поддерживает ряд новых возможностей и обеспечивает прирост производительности, особенно на этапах установки и загрузки гостевых ОС. Применение машин второго поколения сейчас сужает перечень поддерживаемых гостевых ОС, однако для остальных систем можно по-прежнему применять ВМ первого поколения, которые прекрасно сосуществуют с ВМ второго поколения на одном хосте виртуализации.
Дополнительную информацию о новых технологиях Windows Server 2012 R2 вы сможете найти на портале MVA в курсе “Jump Start: Все о Windows Server 2012 R2”.