In Meltdown and Virtual Machines è stato chiarito che almeno Spect funziona incrociando VM . Questo ovviamente significa che l'Hypervisor deve essere corretto, ma
Il sistema operativo della VM dovrebbe essere riparato?
Non essendo vere CPU, non è chiaro se siano direttamente vulnerabili agli attacchi basati su prefetch, o se è sufficiente applicare patch all'Hypervisor.
La mia comprensione, innanzitutto, è che la patch dell'OS / hypervisor mitiga solo Meltdown, non Spectre.
In secondo luogo, si patch l'hypervisor per impedire a una VM di leggere la memoria che appartiene al kernel dell'hypervisor. Applica una patch al SO guest per impedire a un processo di leggere la memoria che appartiene al kernel del SO guest. La mia comprensione è che sono indipendenti l'uno dall'altro; il patching di uno non ha effetto sull'altro.
Emulazione vs virtualizzazione
Non sono un grande esperto di tecnologie di virtualizzazione, ma la tua domanda cade in emulazione vs virtualizzazione : in emulazione la CPU, inclusi tutti i registri, le cache, ecc. è completamente simulata nel software e può utilizzare un set di istruzioni diverso dall'hardware sottostante. Nella virtualizzazione, le istruzioni vengono passate direttamente all'hardware, ma con una pianificazione dei processi aggiuntiva imposta dall'hypervisor. In particolare, la mia comprensione della virtualizzazione x86 , in particolare La tecnologia Intel VT-x , è che si tratta di una" vera CPU "nel senso che il SO guest utilizza istruzioni x86 reali che sono più o meno passati dritto fino all'hardware sottostante.
Quindi sì, il SO guest sarà vulnerabile a Meltdown e richiederà la patch indipendentemente dal fatto che l'hypervisor sia stato corretto.
Ho appena provato su una VM "usa e getta" usando il codice proof of concept da SpectrePoC (che è basato su Spectre Attacks: Exploiting Speculative Execution , e ha funzionato, in quanto sosteneva di essere in grado di sfruttare il sistema. Consiglio vivamente di applicare patch ai kernel guest della macchina virtuale e al kernel host.
In base alle informazioni pubblicate su QEMU, il kernel guest deve essere aggiornato e riavviato dopo l'hypervisor inserisce i nuovi CPUID e Registri macchina. Questo risolve uno dei problemi di Spectre. Purtroppo, QEMU non ha ancora rilasciato la patch sorgente associata al momento della stesura, che dovrebbe essere nella versione 2.11.1, quindi potrebbe essere necessario riavviare di nuovo la VM dopo tale patch se in esecuzione su QEMU. Il kernel guest dovrebbe riconoscere il nuovo CPUID / MR e reagire in modo appropriato. Altri hypervisor (e provider cloud) potrebbero aver già fornito queste modifiche, ma il nuovo kernel è ancora necessario per proteggere il SO guest dalle applicazioni dannose.
Leggi altre domande sui tag virtualization meltdown spectre virtualhost