L’informatica, diciamocelo, è un mondo bello e vario, capace di soddisfare le esigenze più disparate, anche quelle che nella realtà fisica non avrebbero motivo di esistere. Vi immaginate di poter emulare un frullatore all’interno di un forno? Se la frase sembra un non-sense, sappiate che nell’informatica ciò è possibile, grazie alla “magia” delle macchine virtuali! È infatti possibile emulare un intero computer per far girare sistemi obsoleti come Windows XP o, al contrario, ambienti di sviluppo isolati. Questo rende possibile l’esecuzione di vecchi software, il recupero di giochi storici o la creazione di sandbox sicure per testare codice senza rischiare di danneggiare l’host (il PC fisico che ospita la macchina virtuale).
Bello, vero?
La tecnologia avanza e, oggi più che mai, si parla incessantemente di sicurezza informatica: prevenzione di cyberattacchi, data breach, malware e ransomware. I nuovi sistemi operativi e le applicazioni devono rispettare criteri di sicurezza sempre più stringenti. Ma il paradosso è che i software nuovi, apparentemente compatibili e certificati, possono incappare in problemi di funzionamento. Mi riferisco a categorie particolari come gli strumenti di virtualizzazione (VMware, VirtualBox), i software forensi e di recupero dati, o tutte quelle applicazioni che necessitano di un accesso diretto alle risorse di sistema.
Sorge spontanea una domanda: perché questi software commerciali, riconosciuti e ‘trusted’, funzionano male? La risposta sta in un cambiamento di paradigma: il sistema operativo non gestisce più direttamente le risorse, ma cede il passo a un’entità superiore che se le accaparra tutte per sé (il VBS). Una scelta fatta in nome di quella parola per la quale ci si batte — ed è sacrosanto farlo — ma realizzata, a mio avviso, con modi e metodi sbagliati: SICUREZZA.
Questi pensieri hanno preso forma concreta durante un recente intervento presso una cliente che aveva l’urgente necessità di sostituire il proprio portatile. Il vecchio notebook, con oltre 10 anni sulle spalle, presentava le porte USB compromesse (ne funzionava solo una) e Windows 10 mostrava comportamenti anomali: impostazioni che sparivano nel nulla e blocchi casuali del sistema. Le indagini hanno rivelato la causa radice: il disco SSD si stava degradando irreparabilmente. I bad sector stavano aumentando, corrompendo sia i file di lavoro della cliente che quelli di sistema.
Ho effettuato un backup completo di anni di attività, riversando il contenuto su un HDD di riserva. Il nuovo portatile, equipaggiato con un processore Ryzen 7 e 16 GB di RAM, aveva Windows 11 preinstallato. Ho trasferito le cartelle di lavoro sul nuovo SSD, inclusa la macchina virtuale di Windows XP creata con VMware. La cliente utilizza infatti software datato che richiede tassativamente l’uso di una VM. Per questo, ho installato l’ultima versione disponibile di VMware Workstation Pro, la 25H2u1 rilasciata a fine febbraio 2026.
Ed è qui che sono iniziati i problemi.
UNA FORTEZZA INVISIBILE: IL VBS
Le difficoltà sono emerse immediatamente al primo avvio della macchina virtuale. Nonostante l’hardware del nuovo portatile fosse potente, si avviava con prestazioni inaccettabili, quasi “a scatti”, in netto contrasto con la fluidità abituale di Windows 10. Cosa è cambiato nell’architettura del nuovo sistema operativo?
Windows 11 impone requisiti hardware molto più severi rispetto a Windows 10, progettati nello specifico per la sicurezza a livello kernel:
- TPM 2.0 (Trusted Platform Module): Windows 11 richiede obbligatoriamente un chip di sicurezza TPM 2.0. Questo hardware gestisce le chiavi crittografiche e protegge i dati sensibili (come le credenziali di accesso) da attacchi software e firmware. Windows 10 supporta il TPM ma non lo rende obbligatorio per l’installazione.
- Secure Boot: sebbene presente anche su Windows 10, su Windows 11 è configurato in modo più rigido per garantire che solo il software firmato digitalmente e trusted venga eseguito all’avvio, prevenendo rootkit e bootkit.
- VBS e HVCI: Windows 11 attiva di default la Virtualization-Based Security (VBS) e l’Hypervisor-Protected Code Integrity (HVCI) su hardware compatibili. Queste tecnologie isolano parti critiche della memoria del sistema per impedire che codice malevolo venga iniettato nel kernel, una protezione spesso disattivata o opzionale su Windows 10 per garantire compatibilità con hardware e software obsoleto.
In Windows 11 molte funzionalità di sicurezza — in particolare la Virtualization-Based Security (VBS) — utilizzano l’hypervisor di Hyper-V, che viene caricato molto presto durante il processo di avvio. Per questo motivo, disinstallando Hyper-V dalle funzionalità di Windows non si rimuove l’hypervisor ma solo la piattaforma di gestione e gli strumenti associati: se VBS è attivo, l’hypervisor viene comunque avviato prima del caricamento del sistema operativo.
Grazie alle estensioni di virtualizzazione delle CPU moderne (Intel VT-x o AMD-V), l’hypervisor opera a un livello di privilegio superiore rispetto al kernel del sistema operativo (spesso indicato come Ring −1), assumendo il controllo diretto dell’hardware prima ancora che Windows venga avviato.
Di conseguenza, Windows non gira più direttamente sull’hardware: il sistema operativo viene eseguito sopra l’hypervisor nella cosiddetta root partition. Il kernel principale opera nel livello di fiducia standard (VTL0), mentre alcune componenti di sicurezza sensibili vengono isolate tramite VBS in un ambiente separato (VTL1), protetto dall’hypervisor. Questo meccanismo permette di isolare elementi critici del sistema — come credenziali e parti sensibili del kernel — anche nel caso in cui il sistema operativo venga compromesso.
Questa architettura ha però un effetto collaterale per i software di virtualizzazione desktop. Strumenti come VMware Workstation, che tradizionalmente accedevano direttamente alle estensioni di virtualizzazione della CPU, non possono più farlo quando VBS è attivo. Devono invece utilizzare le API della Windows Hypervisor Platform, operando quindi sopra l’hypervisor di Microsoft invece che direttamente sull’hardware.
Il risultato è uno strato di astrazione in più tra il software di virtualizzazione e la CPU. Nella maggior parte dei casi l’impatto è moderato, ma in alcuni scenari — ad esempio con carichi di virtualizzazione intensivi o con virtualizzazione annidata — può tradursi in un calo prestazionale rispetto a una configurazione in cui Hyper-V non è attivo e l’hypervisor desktop può accedere direttamente all’hardware.
In altre parole, per costruire questa “fortezza” di sicurezza è stato aggiunto un piano in più all’edificio. VMware, che prima entrava direttamente dall’ingresso principale, ora deve passare per le scale di servizio di questo nuovo piano e chiedere all’hypervisor di Microsoft Hyper-V di accedere all’hardware. Il percorso è più lungo, e questo può tradursi in maggiore latenza.
E quindi—ritornando all’immagine di apertura e alla sua domanda—come la risolviamo?
NON SERVE UN MAGO: SERVE TRASPARENZA – PASSO 1
In questi casi potrebbe servire (ahimè) la figura di “mio cuggino smanettone”, essere mitologico che si colloca proprio in mezzo tra chi progetta software ed il bistrattato utente finale.
Ha un’aura quasi mistica, risolve qualsiasi tipo di magagna sotto lo sguardo attonito della persona di turno: come diavolo ha fatto a capire che era quello il problema, nonostante non si riesce a vederne il nesso logico e causale! Beh, cara persona di turno, lascia che ti dica una cosa: hai perfettamente ragione a non vederlo!
Il motivo per cui il tuo software, pur certificato per Windows 11, ha prestazioni misere non è un mistero arcano, ma la conseguenza di una precisa scelta architetturale, ma opaca a livello comunicativo: la visione di Microsoft è “SICUREZZA prima di tutto”. E quando dicono “prima di tutto”, intendono letteralmente:
- Prima che il sistema operativo venga eseguito, il suo hypervisor mette le mani su tutto.
- Prima che il kernel possa dialogare con l’hardware, è già chiuso nella sua campana di vetro virtualizzata.
- Prima che l’utente possa anche solo realizzare cosa sta succedendo.
Microsoft e Broadcom hanno documentato tecnicamente il problema? Sì. Lo hanno comunicato all’utente finale durante l’installazione o l’esecuzione? Assolutamente no. L’utente viene ignorato, lasciato solo davanti a un calo di prestazioni inspiegabile.
È qui che serve un cambio di rotta. Serve che chi sviluppa software restituisca trasparenza e scelta. Immaginate un installer di VMware (o una finestra pop-up del sistema operativo stesso) che dicesse chiaramente:
Semplice, vero? Si restituisce all’utente il potere di scegliere in modo consapevole, senza dover scomodare il supereroe di turno che armeggia con gpedit.msc, comandi CMD oscuri o modifiche al registro di sistema.
L’EROE INASPETTATO: QUANDO I TOOL DI TERZE PARTI SALVANO LA SITUAZIONE – PASSO 2
Se i grandi colossi non offrono questa trasparenza, ci pensa spesso la passione di singoli sviluppatori. In questo caso, il salvavita si chiama Wintoys. Credo che vince a mani basse il titolo di uno dei migliori programmi per Windows 11, e lo dico con sincero apprezzamento per la semplicità che riesce a restituire all’esperienza utente. Raggruppa in un’unica interfaccia pulita tutte le opzioni nascoste tra i meandri di Impostazioni e Pannello di controllo, rendendo tutto chiaro, ordinato e facilmente fruibile. C’è bisogno di avere 2 voci distinte per le impostazioni di sistema?
Un grazie allo sviluppatore Bogdan Pătrăucean e a tutti coloro che, per passione e spirito di servizio, creano strumenti che mettono l’utente al primo posto.
Grazie a Wintoys, ho potuto spiegare alla cliente come risolvere la lentezza delle macchine virtuali in pochi secondi, senza scendere troppo in tecnicismi. È bastato avviare il programma, andare alla voce Prestazioni e disattivare la voce VBS (come mostrato nello screenshot qui sotto).
Un paio di click, un riavvio et voilà, PROBLEMA RISOLTO! La potenza della semplicità e della chiarezza al servizio dell’utente.
Nota importante sulla sicurezza: disattivare VBS/HVCI espone il sistema a rischi maggiori (come malware a livello di kernel), ma il fatto che Microsoft permetta di farlo significa che il PC rimane perfettamente utilizzabile. Per un utente consapevole che necessita di prestazioni massime in virtualizzazione per lavoro, è un compromesso accettabile e gestibile, a patto di mantenere buone pratiche di navigazione, non eseguire software sospetto e fare backup regolari. La sicurezza non dovrebbe mai essere una gabbia senza chiave d’uscita.
CONCLUSIONI
Cosa abbiamo imparato da questa avventura? Principalmente due cose.
- Non esiste un “lasciapassare” magico. Non c’è modo di autorizzare VMware come applicazione “fidata” per avere accesso diretto alla CPU mantenendo attive le sicurezze di Windows 11. Non è una questione di permessi o firme digitali, ma di architettura: quando VBS è attivo, l’hypervisor di Microsoft si posiziona fisicamente tra il software e l’hardware. Nemmeno il kernel di Windows ha più il controllo diretto. Per ridare a VMware l’accesso nativo, l’unica via è disattivare lo strato di virtualizzazione di Microsoft, accettando il compromesso di ridurre alcune difese del sistema operativo.
- Il software deve essere chiaro e accessibile. L’utente deve essere riportato al centro dell’ecosistema software, con la possibilità di scegliere in maniera consapevole ed informata. Nascondere la complessità o addirittura—come nel nostro caso—un’incompatibilità dovuta a una precisa scelta progettuale, non significa risolvere i problemi ma solo spostarli sulle spalle di chi, come il “cuggino smanettone” o i piccoli sviluppatori di utility, deve poi rimediare.
Quando l’implementazione di misure di sicurezza avanzate avviene in silenzio, rendendo di fatto inutilizzabili strumenti che prima funzionavano perfettamente, non si sta proteggendo l’utente: lo si sta estromettendo. È un atto di superbia tecnica che trasforma il proprietario del PC in un semplice ospite sulla propria macchina, che chiede solo di esercitare un diritto fondamentale: usare il proprio hardware e software.
La tecnologia dovrebbe supportare ed amplificare le capacità umane, non richiedere una laurea in ingegneria per dei compiti che essa stessa dovrebbe semplificare. È tempo di restituire all’utente il ruolo di protagonista: serve ripristinare quel dialogo trasparente che oggi sembra spezzato, facendo tornare l’accessibilità e la scelta consapevole al centro del progresso tecnologico. Nessuna sicurezza dovrebbe costare la libertà di controllo.
