Condividi tramite


Informazioni sulla selezione del tipo di utilità di pianificazione dell'hypervisor Hyper-V

Questo documento descrive le importanti modifiche apportate alle impostazioni predefinite di Hyper-V e sull'uso consigliato dei tipi di utilità di pianificazione dell'hypervisor. Tali modifiche influiscono sia sulla sicurezza del sistema che sulle prestazioni di virtualizzazione. Gli amministratori host di virtualizzazione devono esaminare e comprendere le modifiche e le implicazioni descritte in questo documento, nonché valutare attentamente gli impatti, le indicazioni suggerite sulla distribuzione e i fattori di rischio coinvolti per comprendere meglio come distribuire e gestire gli host Hyper-V nel panorama della sicurezza in rapida evoluzione.

Importante

Al momento, le vulnerabilità di sicurezza lato canale note rilevate in più architetture del processore possono essere sfruttate da una macchina virtuale guest dannosa tramite il comportamento di pianificazione del tipo di utilità di pianificazione classico dell'hypervisor quando viene eseguito negli host con multithreading simultaneo (SMT) abilitato. Se usato correttamente, un carico di lavoro dannoso potrebbe osservare i dati al di fuori del limite della partizione. Questa classe di attacchi può essere mitigata configurando l'hypervisor Hyper-V in modo da usare il tipo di utilità di pianificazione principale dell'hypervisor e riconfigurando le macchine virtuali guest. Con l'utilità di pianificazione principale, l'hypervisor limita l'esecuzione dei VP di una macchina virtuale guest nello stesso core del processore fisico, isolando fortemente quindi la capacità della macchina virtuale di accedere ai dati ai limiti del core fisico in cui viene eseguito. Si tratta di una mitigazione estremamente efficace contro questi attacchi sul lato canale, che impedisce alla macchina virtuale di osservare eventuali artefatti da altre partizioni, indipendentemente dalla radice o da un'altra partizione guest. Pertanto, Microsoft sta modificando le impostazioni di configurazione predefinite e consigliate per gli host di virtualizzazione e le macchine virtuali guest.

Background

A partire da Windows Server 2016, Hyper-V supporta diversi metodi di pianificazione e gestione dei processori virtuali, noti come tipi di utilità di pianificazione dell'hypervisor. Una descrizione dettagliata di tutti i tipi di utilità di pianificazione hypervisor è disponibile in Informazioni e uso dei tipi di utilità di pianificazione hypervisor Hyper-V.

Nota

I nuovi tipi di utilità di pianificazione dell'hypervisor sono stati introdotti per la prima volta con Windows Server 2016 e non sono disponibili nelle versioni precedenti. Tutte le versioni di Hyper-V precedenti a Windows Server 2016 supportano solo l'utilità di pianificazione classica. Il supporto per l'utilità di pianificazione principale è stato pubblicato solo di recente.

Informazioni sui tipi di utilità di pianificazione dell'hypervisor

Questo articolo è incentrato in particolare sull'uso del nuovo tipo di utilità di pianificazione principale dell'hypervisor rispetto all'utilità di pianificazione "classica" legacy e sul modo in cui questi tipi di utilità di pianificazione si intersecano con l'uso di SMT. È importante comprendere le differenze tra le utilità di pianificazione principali e classiche e il funzionamento di ogni posizione dalle macchine virtuali guest nei processori di sistema sottostanti.

Utilità di pianificazione classica

L'utilità di pianificazione classica si riferisce al metodo di equa condivisione round robin di pianificare il lavoro nei processori virtuali (VP) nel sistema, inclusi i VP radice quelli appartenenti alle macchine virtuali guest. L'utilità di pianificazione classica è il tipo di utilità di pianificazione predefinito usato in tutte le versioni di Hyper-V (fino a Windows Server 2019, come descritto di seguito). Le caratteristiche delle prestazioni dell'utilità di pianificazione classica sono ben comprensibili ed è dimostrato che supporta in modo efficiente l'over-subscription dei carichi di lavoro, ovvero l'over-subscription del rapporto VP:LP dell'host in base a un margine ragionevole (a seconda dei tipi di carichi di lavoro virtualizzati, dell'utilizzo complessivo delle risorse e così via).

Quando viene eseguito in un host di virtualizzazione con SMT abilitato, l'utilità di pianificazione classica pianifica i VP guest da qualsiasi macchina virtuale in ogni thread SMT appartenente a un core in modo indipendente. Di conseguenza, è possibile eseguire macchine virtuali diverse nello stesso core contemporaneamente (una macchina virtuale in esecuzione in un thread di un core mentre un'altra macchina virtuale è in esecuzione nell'altro thread).

Utilità di pianificazione principale

L'utilità di pianificazione principale sfrutta le proprietà di SMT per fornire l'isolamento dei carichi di lavoro guest, che influiscono sulle prestazioni di sicurezza e di sistema. L'utilità di pianificazione principale garantisce che VP da una macchina virtuale siano pianificate in thread SMT di pari livello. Questa operazione viene eseguita in modo simmetrico così che se gli LP si trovano in gruppi di due, i VP vengono pianificate in gruppi di due e un core CPU di sistema non viene mai condiviso tra le macchine virtuali.

Pianificando i VP guest sulle coppie SMT sottostanti, l'utilità di pianificazione principale offre un limite di sicurezza sicuro per l'isolamento del carico di lavoro e può essere usato anche per ridurre la variabilità delle prestazioni per i carichi di lavoro sensibili alla latenza.

Si noti che quando il VP è pianificato per una macchina virtuale senza SMT abilitata, tale VP utilizzerà l'intero core durante l'esecuzione e il thread SMT di pari livello del core verrà lasciato inattiva. Ciò è necessario per garantire l'isolamento corretto del carico di lavoro, ma influisce sulle prestazioni complessive del sistema, in particolare quando gli LP di sistema diventano over-subscribed, ovvero quando il rapporto VP:LP totale supera 1:1. Pertanto, l'esecuzione di macchine virtuali guest configurate senza più thread per core è una configurazione non ottimale.

Vantaggi dell'uso dell'utilità di pianificazione principale

L'utilità di pianificazione principale offre i vantaggi seguenti:

  • Un limite di sicurezza sicuro per l'isolamento del carico di lavoro guest: i VP guest sono vincolati all'esecuzione su coppie di core fisici sottostanti, riducendo la vulnerabilità agli attacchi di snooping sul lato canale.

  • Riduzione della variabilità del carico di lavoro: la variabilità della velocità effettiva del carico di lavoro guest è notevolmente ridotta e offre maggiore coerenza del carico di lavoro.

  • Uso di SMT nelle macchine virtuali guest: il sistema operativo e le applicazioni in esecuzione nella macchina virtuale guest possono usare il comportamento SMT e le interfacce di programmazione (API) per controllare e distribuire il lavoro tra thread SMT, proprio come quando vengono eseguiti non virtualizzati.

L'utilità di pianificazione principale viene attualmente usata negli host di virtualizzazione di Azure, in particolare per sfruttare i potenti limiti di sicurezza e la variabilità del carico di lavoro bassa. Microsoft ritiene che il tipo di utilità di pianificazione principale sia e continuerà a essere il tipo di pianificazione dell'hypervisor predefinito per la maggior parte degli scenari di virtualizzazione. Pertanto, per garantire che i clienti siano protetti per impostazione predefinita, Microsoft sta apportando questa modifica per Windows Server 2019.

Impatti delle prestazioni dell'utilità di pianificazione di base sui carichi di lavoro guest

Anche se necessario per attenuare in modo efficace determinate classi di vulnerabilità, l'utilità di pianificazione principale può anche potenzialmente ridurre le prestazioni. I clienti possono riscontrare una differenza nelle caratteristiche delle prestazioni con le macchine virtuali e un impatto sulla capacità complessiva del carico di lavoro degli host di virtualizzazione. Nei casi in cui l'utilità di pianificazione principale deve eseguire un VP non SMT, viene eseguito solo uno dei flussi di istruzioni nel core logico sottostante mentre l'altro deve essere lasciato inattivo. In questo modo verrà limitata la capacità totale dell'host per i carichi di lavoro guest.

Questi impatti sulle prestazioni possono essere ridotti al minimo seguendo le indicazioni sulla distribuzione in questo documento. Gli amministratori host devono considerare attentamente gli scenari di distribuzione di virtualizzazione specifici e bilanciare la tolleranza per il rischio della sicurezza in base alla necessità di densità massima del carico di lavoro, oltre al consolidamento degli host di virtualizzazione e così via.

La distribuzione degli host Hyper-V con il comportamento di sicurezza massimo richiede l'uso del tipo di utilità di pianificazione principale dell'hypervisor. Per assicurarsi che i clienti siano protetti per impostazione predefinita, Microsoft sta modificando le impostazioni predefinite e consigliate seguenti.

Nota

Mentre il supporto interno dell'hypervisor per i tipi di utilità di pianificazione è stato incluso nella versione iniziale di Windows Server 2016, Windows Server 1709 e Windows Server 1803, gli aggiornamenti sono necessari per accedere al controllo di configurazione che consente di selezionare il tipo di utilità di pianificazione dell'hypervisor. Per informazioni dettagliate su questi aggiornamenti, vedere Informazioni e uso dei tipi di utilità di pianificazione hypervisor Hyper-V.

Modifiche all'host di virtualizzazione

  • L'hypervisor userà l'utilità di pianificazione principale per impostazione predefinita a partire da Windows Server 2019.

  • Microsoft consiglia di configurare l'utilità di pianificazione principale in Windows Server 2016. Il tipo di utilità di pianificazione principale dell'hypervisor è supportato in Windows Server 2016, ma il valore predefinito è l'utilità di pianificazione classica. L'utilità di pianificazione principale è facoltativa e deve essere abilitata in modo esplicito dall'amministratore dell'host Hyper-V.

Modifiche alla configurazione della macchina virtuale

  • In Windows Server 2019, le nuove macchine virtuali create con la macchina virtuale predefinita versione 9.0 erediteranno automaticamente le proprietà SMT (abilitate o disabilitate) dell'host di virtualizzazione. In altre parole, se SMT è abilitato nell'host fisico, le macchine virtuali appena create avranno anche SMT abilitato ed erediteranno la topologia SMT dell'host per impostazione predefinita, con la macchina virtuale con lo stesso numero di thread hardware per core del sistema sottostante. Ciò si rifletterà nella configurazione della macchina virtuale con HwThreadCountPerCore = 0, dove 0 indica che la macchina virtuale deve ereditare le impostazioni SMT dell'host.

  • Le macchine virtuali esistenti con una versione 8.2 della macchina virtuale o versioni precedenti manterranno l'impostazione originale del processore della macchina virtuale per HwThreadCountPerCore e l'impostazione predefinita per i guest della versione 8.2 della macchina virtuale è HwThreadCountPerCore = 1. Quando questi guest vengono eseguiti in un host di Windows Server 2019, verranno considerati come segue:

    1. Se la macchina virtuale ha un conteggio VP minore o uguale al numero di core LP, la macchina virtuale verrà considerata come una macchina virtuale non SMT dall'utilità di pianificazione principale. Quando il VP guest viene eseguito in un singolo thread SMT, il thread SMT di pari livello del core verrà reso inattivo. Ciò non è ottimale e comporterà una perdita complessiva delle prestazioni.

    2. Se la macchina virtuale ha più VP rispetto ai core LP, la macchina virtuale verrà considerata come una macchina virtuale SMT dall'utilità di pianificazione principale. Tuttavia, la macchina virtuale non osserverà altre indicazioni che si tratta di una macchina virtuale SMT. Ad esempio, l'uso dell'istruzione CPUID o delle API di Windows per eseguire query sulla topologia della CPU dal sistema operativo o dalle applicazioni non indicherà che SMT è abilitato.

  • Quando una macchina virtuale esistente viene aggiornata in modo esplicito dalle versioni precedenti alla versione 9.0 tramite l'operazione Update-VM, la macchina virtuale manterrà il valore corrente per HwThreadCountPerCore. La macchina virtuale non avrà SMT forzato abilitato.

  • In Windows Server 2016, Microsoft consiglia di abilitare SMT per le macchine virtuali guest. Per impostazione predefinita, le macchine virtuali create in Windows Server 2016 hannon disabilitato SMT, ovvero HwThreadCountPerCore è impostato su 1, a meno che non venga modificato in modo esplicito.

Nota

Windows Server 2016 non supporta l'impostazione di HwThreadCountPerCore su 0.

Gestione della configurazione SMT della macchina virtuale

La configurazione SMT della macchina virtuale guest viene impostata per ogni macchina virtuale. L'amministratore host può esaminare e impostare la configurazione SMT di una macchina virtuale per selezionare le opzioni seguenti:

  1. Configurare le macchine virtuali per l'esecuzione come SMT abilitato, ereditando automaticamente in modo facoltativo la topologia SMT dell'host

  2. Configurare le macchine virtuali per l'esecuzione come non SMT

La configurazione SMT per una macchina virtuale viene visualizzata nei riquadri Riepilogo della console di gestione di Hyper-V. La configurazione delle impostazioni SMT di una macchina virtuale può essere eseguita usando le impostazioni della macchina virtuale o PowerShell.

Configurazione delle impostazioni SMT della macchina virtuale tramite PowerShell

Per configurare le impostazioni SMT per una macchina virtuale guest, aprire una finestra di PowerShell con autorizzazioni sufficienti e digitare:

Set-VMProcessor -VMName <VMName> -HwThreadCountPerCore <0, 1, 2>

Dove:

  • 0 = Ereditare la topologia SMT dall'host (questa impostazione di HwThreadCountPerCore=0 non è supportata in Windows Server 2016)

  • 1 = Non-SMT

  • I valori > 1 = il numero desiderato di thread SMT per core. Non può superare il numero di thread SMT fisici per core.

Per leggere le impostazioni SMT per una macchina virtuale guest, aprire una finestra di PowerShell con autorizzazioni sufficienti e digitare:

(Get-VMProcessor -VMName <VMName>).HwThreadCountPerCore

Si noti che le macchine virtuali guest configurate con HwThreadCountPerCore = 0 indicano che SMT verrà abilitato per il guest ed esporrà lo stesso numero di thread SMT al guest in quanto si trovano nell'host di virtualizzazione sottostante, in genere 2.

Le macchine virtuali guest possono osservare modifiche alla topologia della CPU in scenari di mobilità delle macchine virtuali

Il sistema operativo e le applicazioni in una macchina virtuale possono visualizzare le modifiche alle impostazioni dell'host e della macchina virtuale prima e dopo gli eventi del ciclo di vita della macchina virtuale, ad esempio la migrazione in tempo reale o le operazioni di salvataggio e ripristino. Durante un'operazione in cui viene salvato e ripristinato lo stato della macchina virtuale, viene eseguita la migrazione dell'impostazione HwThreadCountPerCore della macchina virtuale e del valore realizzato (ovvero la combinazione calcolata dell'impostazione della macchina virtuale e della configurazione dell'host di origine). La macchina virtuale continuerà a essere in esecuzione con queste impostazioni nell'host di destinazione. Al momento dell'arresto e del riavvio della macchina virtuale, è possibile che il valore realizzato osservato dalla macchina virtuale cambierà. Questo comportamento non dovrebbe essere dannoso, perché il software del sistema operativo e dell'applicazione deve cercare informazioni sulla topologia della CPU come parte dei normali flussi di codice di avvio e inizializzazione. Tuttavia, poiché queste sequenze di inizializzazione dell'ora di avvio vengono ignorate durante la migrazione in tempo reale o le operazioni di salvataggio/ripristino, le macchine virtuali che subiscono queste transizioni di stato potrebbero osservare il valore realizzato originariamente calcolato fino a quando non vengono arrestate e riavviate.

Avvisi relativi alle configurazioni di macchine virtuali non ottimali

Le macchine virtuali configurate con più VP rispetto ai core fisici nell'host generano una configurazione non ottimale. L'utilità di pianificazione dell'hypervisor considererà queste macchine virtuali come se fossero compatibile con SMT. Tuttavia, il software del sistema operativo e dell'applicazione nella macchina virtuale presenterà una topologia della CPU che mostra che SMT è disabilitato. Quando viene rilevata questa condizione, il processo di lavoro Hyper-V registrerà un evento nell'host di virtualizzazione che avvisa l'amministratore host che la configurazione della macchina virtuale non è ottimale e consiglia di abilitare SMT per la macchina virtuale.

Come identificare macchine virtuali non configurate in modo ottimale

È possibile identificare le macchine virtuali non SMT esaminando il registro di sistema nel Visualizzatore eventi per l'ID 3498 dell'evento del processo di lavoro di Hyper-V, che verrà attivato per una macchina virtuale ogni volta che il numero di VP nella macchina virtuale è maggiore del numero di core fisici. Gli eventi del processo di lavoro possono essere ottenuti dal Visualizzatore eventi o tramite PowerShell.

Esecuzione di query sull'evento della macchina virtuale del processo di lavoro Hyper-V con PowerShell

Per eseguire una query per l'ID 3498 dell'evento del processo di lavoro Hyper-V 3498 usando PowerShell, immettere i comandi seguenti da un prompt di PowerShell.

Get-WinEvent -FilterHashTable @{ProviderName="Microsoft-Windows-Hyper-V-Worker"; ID=3498}

Impatto della configurazione SMT guest sull'uso delle funzionalità di riconoscimento dei dati di hypervisor per i sistemi operativi guest

L'hypervisor Microsoft offre più funzionalità di riconoscimento dei dati, o suggerimenti, su sui il sistema operativo in esecuzione in una macchina virtuale guest può eseguire query e usare per attivare ottimizzazioni, ad esempio quelle che potrebbero migliorare le prestazioni o migliorare in altro modo la gestione delle varie condizioni durante l'esecuzione virtualizzata. Uno dei concetti di riconoscimento dei dati introdotti di recente riguarda la gestione della pianificazione del processore virtuale e l'uso di mitigazioni del sistema operativo per gli attacchi sul canale laterale che sfruttano SMT.

Nota

Microsoft consiglia agli amministratori host di abilitare SMT per le macchine virtuali guest per ottimizzare le prestazioni del carico di lavoro.

I dettagli di questa funzionalità di riconoscimento dei dati guest sono forniti di seguito, ma la chiave per gli amministratori host di virtualizzazione è che le macchine virtuali devono avere HwThreadCountPerCore configurato in modo che corrisponda alla configurazione SMT fisica dell'host. In questo modo l'hypervisor può segnalare che non esiste alcuna condivisione di core non architetturali. Di conseguenza, qualsiasi sistema operativo guest che supporta le ottimizzazioni che richiedono il riconoscimento dei dati può essere abilitato. In Windows Server 2019, creare nuove macchine virtuali e lasciare il valore predefinito HwThreadCountPerCore (0). Le macchine virtuali meno recenti migrate dagli host Windows Server 2016 possono essere aggiornate alla versione di configurazione di Windows Server 2019. Al termine, Microsoft consiglia di impostare HwThreadCountPerCore = 0. In Windows Server 2016, Microsoft consiglia di impostare HwThreadCountPerCore in modo che corrisponda alla configurazione dell'host (in genere 2).

Dettagli sul riconoscimento dei dati NoNonArchitecturalCoreSharing

A partire da Windows Server 2016, l'hypervisor definisce un nuovo riconoscimento dei dati per descrivere la gestione della pianificazione e del posizionamento di VP nel sistema operativo guest. Il riconoscimento dati è definito nella specifica funzionale di livello superiore dell'hypervisor v5.0c.

La foglia CPUID sintetica dell'hypervisor CPUID.0x40000004.EAX:18[NoNonArchitecturalCoreSharing = 1] indica che un processore virtuale non condividerà mai un core fisico con un altro processore virtuale, ad eccezione dei processori virtuali segnalati come thread SMT di pari livello. Ad esempio, un VP guest non verrà mai eseguito su un thread SMT insieme a un VP radice in esecuzione simultaneamente su un thread SMT di pari livello nello stesso core del processore. Questa condizione è possibile solo quando si esegue virtualizzato e quindi rappresenta un comportamento SMT non architetturale che ha anche gravi implicazioni per la sicurezza. Il sistema operativo guest può usare NoNonArchitecturalCoreSharing = 1 come indicazione che è sicuro abilitare le ottimizzazioni, evitando così il sovraccarico delle prestazioni dell'impostazione di STIBP.

In determinate configurazioni, l'hypervisor non indicherà NoNonArchitecturalCoreSharing = 1. Ad esempio, se un host ha SMT abilitato ed è configurato per l'uso dell'utilità di pianificazione classica dell'hypervisor, NoNonArchitecturalCoreSharing sarà 0. Ciò potrebbe impedire agli utenti guest con riconoscimento dei dati di abilitare determinate ottimizzazioni. Microsoft consiglia pertanto agli amministratori host di usare SMT con l'utilità di pianificazione principale dell'hypervisor e assicurarsi che le macchine virtuali siano configurate per ereditare la configurazione SMT dall'host per garantire prestazioni ottimali del carico di lavoro.

Riepilogo

Il panorama delle minacce per la sicurezza continua a evolversi. Per garantire che i clienti siano sicuri per impostazione predefinita, Microsoft sta modificando la configurazione predefinita per l'hypervisor e le macchine virtuali a partire da Windows Server 2019 Hyper-V e fornendo indicazioni e consigli aggiornati per i clienti che eseguono Windows Server 2016 Hyper-V. Gli amministratori host di virtualizzazione devono:

  • Leggere e comprendere le indicazioni fornite in questo documento

  • Valutare e modificare attentamente le distribuzioni di virtualizzazione per garantire che soddisfino gli obiettivi di sicurezza, prestazioni, densità di virtualizzazione e velocità di risposta del carico di lavoro per i requisiti univoci

  • Valutare la possibilità di riconfigurare gli host Hyper-V di Windows Server 2016 esistenti per sfruttare i vantaggi di sicurezza avanzata offerti dall'utilità di pianificazione principale dell'hypervisor

  • Aggiornare le macchine virtuali non SMT esistenti per ridurre gli effetti sulle prestazioni derivanti dai vincoli di pianificazione imposti dall'isolamento VP che risolve le vulnerabilità di sicurezza hardware