Я знаю, что гипервизоры Vmware, по крайней мере, имеют настройку игнорировать обновления микрокода процессора из гостевой ОС (неудивительно).
Доступно обновление микрокода ЦП. Гостевая ОС попыталась обновить микрокод с уровня исправления XX (YYh) до уровня исправления ZZ (TTh), но VMware ESX не позволяет применять исправления микрокода изнутри виртуальной машины. Патчи микрокода используются для исправления ошибок ЦП. Если у вас нет проблем с вашим процессором, вы можете игнорировать этот патч микрокода. В противном случае вы можете получить обновление BIOS / микропрограммы, которое включает этот патч микрокода, от поставщика вашей системы, или ваша ОС хоста может предоставить средство для загрузки патчей микрокода, полученных непосредственно с веб-сайта Intel.
https://kb.vmware.com/s/article/1028290
Это относится ко всем гипервизорам (например, KVM, где представлен виртуальный ЦП Qemu), или, возможно, есть настройка для Vmware Vsphere, где обнаруженное обновление микрокода с гостевой машины настраивается для использования механизмом загрузки микрокода гипервизора (например, когда микрокод подлинный и версия новее установленного микрокода)?
Ни одна гостевая машина не может загружать микрокод в ЦП гипервизора, за исключением случаев, когда микрокод предназначен для виртуализированного ЦП. Но опять же, какая от этого польза? Код гипервизора также можно обновить, чтобы просто изменить виртуальный процессор.
Spectre необходимо смягчить на уровне гипервизора, и поэтому гипервизору требуется соответствующая прошивка Bios и / или загрузка микрокода. Микрокод не может быть исправлен через гостевую ОС.
Red Hat отозвала обновления микрокода, связанные со Spectre, и виртуальные машины пытаются загрузить микрокод во время загрузки.
Пн, 15 января 2018 г. Петр Орос - 1: 1.17-25.4 Использовать исходный код восходящего потока для отката. Решает: # 1533978
Пт, 12 января 2018 г. Петр Орос - 1: 1.17-25.3 Восстановление микрокода от Intel и AMD для атаки по побочному каналу Решение: # 1533978
Список изменений RPM microcode_ctl
Да, гипервизоры (по крайней мере те, которые не являются необычно сломанными) будут всегда отказать гостю в доступе к обновлению микрокода (ВМ). Любые обновления микрокода должны доставляться либо самим гипервизором, либо системной прошивкой / загрузчиком.
Причина этого наиболее очевидна: безопасность. Обновление микрокода может изменить видимые детали ISA (архитектура набора команд) и нарушить работу всей системы, вплоть до сбоя других виртуальных машин, которые не были подготовлены к изменениям ISA, и т. Д. (См. Исправление микрокода Intel TSX, которое удалило Инструкции Intel TSX-NI для примера).
Кроме того, существуют атаки на уровне обновления микрокода, и в случае успеха они приведут к отказу всей системы. Таким образом, одна виртуальная машина может привести к сбою гипервизора и всех других виртуальных машин. См. Пример в статье Inertiawar об обновлениях микрокода Intel.
Кроме того, гипервизор может предоставить гостю другую, иногда синтезированную модель ЦП, отличную от той, на которой он действительно работает. Гостю незачем пытаться обновить микрокод такого процессора.
Таким образом, обновления микрокода - это поверхность атаки, когда все стоящие гипервизоры будут закрыты.