As atualizações do microcódigo da CPU são sempre ignoradas pelos hipervisores?

Question

Pergunta

Eu sei que os hypervisors Vmware têm pelo menos uma configuração para ignorar as atualizações de microcódigo da CPU de dentro do sistema operacional convidado (sem surpresa).

CPU microcode update available. The guest OS tried to update the microcode from patch level XX (YYh) to patch level ZZ (TTh), but VMware ESX does not allow microcode patches to be applied from within a virtual machine. Microcode patches are used to correct CPU errata. If you are not experiencing any problems with your CPU, you can ignore this microcode patch. Otherwise, you may be able to obtain a BIOS/firmware update which includes this microcode patch from your system vendor, or your host OS may provide a facility for loading microcode patches obtained directly from the Intel web site.

link

Este é o caso de todos os hipervisores (como o KVM, onde uma CPU Virtual Qemu é apresentada) ou há talvez uma configuração para o VMware Vsphere onde a atualização de microcódigo detectada da máquina convidada é preparada para ser usada pelo carregamento do microcódigo de hipervisores mecanismo (por exemplo, quando o microcódigo é autêntico e a versão é mais recente que o microcódigo instalado)?

Suposições

1. Nenhuma máquina convidada pode fazer o upload de microcódigo para a CPU do hipervisor, exceto quando o microcódigo é específico para uma CPU virtualizada. Mas, novamente, que uso teria? O código do hipervisor também pode ser atualizado para apenas alterar a CPU virtual.

2. O Spectre precisa ser atenuado no nível do hipervisor e, portanto, precisa de uploads adequados de firmware e / ou microcódigo do Bios pelo hipervisor. O microcódigo não pode ser corrigido pelo sistema operacional convidado.

Antecedentes

Atualizações de microcódigo retiradas da Red Hat relacionadas ao Specter e as máquinas virtuais tentam fazer o upload do microcódigo durante a inicialização.

Mon Jan 15 2018 Petr Oros - 1:1.17-25.4 Use right upstream source for revert Resolves: #1533978

Fri Jan 12 2018 Petr Oros - 1:1.17-25.3 Revert Microcode from Intel and AMD for Side Channel attack Resolves: #1533978

Changelog do RPM do microcode_ctl

    

Answer 1

Sim, hipervisores (os que não são quebrados de forma incomum, pelo menos) sempre recusam o acesso de atualização de microcódigo de convidados (VMs). Quaisquer atualizações de microcódigo devem ser entregues pelo próprio hypervisor ou pelo firmware do sistema / carregador de inicialização.

A razão para isso é a mais óbvia: segurança. Uma atualização de microcódigo pode alterar detalhes visíveis do ISA (arquitetura de conjunto de instruções) e perturbar todo o sistema, incluindo até mesmo a falha de outras VMs que não foram preparadas para as alterações do ISA, etc (consulte a correção de microcódigo do Intel TSX que removeu Instruções da Intel TSX-NI para um exemplo).

Além disso, existem ataques de nível de atualização de microcódigo e, quando bem-sucedidos, derrubarão todo o sistema. Assim, uma VM pode travar o hipervisor e todas as outras VMs. Consulte o artigo Inertiawar sobre atualizações de microcódigo da Intel para um exemplo.

Além disso, um hypervisor pode expor ao convidado um modelo de CPU diferente, às vezes sintetizado, do que aquele em que ele realmente está sendo executado. O convidado não tem nenhum negócio tentando atualizar o microcódigo de tal CPU.

As atualizações de microcódigo são, portanto, uma superfície de ataque. Todos os hipervisores que valham alguma coisa serão encerrados.