🐧 Novità principali
- Ubuntu 26.04 LTS introduce uno stack HWE opzionale che aggiornerà QEMU, libvirt e firmware di virtualizzazione ogni sei mesi.
- Il nuovo modello porta sull’edizione LTS le future funzioni di confidential computing senza obbligare le aziende a usare release intermedie.
- fwupd 2.1.7 aggiunge controlli su cifratura, Secure Boot e firmware UEFI, correggendo anche diversi problemi di sicurezza e affidabilità.
Canonical estende il modello Hardware Enablement alla virtualizzazione di Ubuntu 26.04 LTS, consentendo alle infrastrutture aziendali di ricevere versioni più recenti di QEMU, libvirt, EDK2 e SeaBIOS senza abbandonare la stabilità della release a lungo supporto. Lo stack, facoltativo e aggiornato ogni sei mesi, nasce soprattutto per accompagnare l’evoluzione del confidential computing, dove kernel, hypervisor e firmware devono avanzare in modo coordinato. Parallelamente, fwupd 2.1.7 amplia i controlli sulla sicurezza del firmware Linux, integra systemd-pcrlock negli aggiornamenti UEFI e rende più rigorosa la verifica dei metadati utilizzati per distribuire nuove versioni ai dispositivi.
Cosa leggere
Ubuntu porta il modello HWE dentro la virtualizzazione
Ubuntu utilizza da anni gli stack HWE per offrire kernel e componenti grafici più recenti agli utenti delle versioni LTS. Con Ubuntu 26.04 LTS Resolute Raccoon, Canonical applica lo stesso principio anche alla virtualizzazione, separando lo stack base da una variante aggiornata periodicamente. I nuovi pacchetti sono qemu-hwe, dedicato all’emulazione e all’hypervisor, libvirt-hwe, utilizzato per la gestione delle macchine virtuali, edk2-hwe, che comprende il firmware UEFI OVMF, e seabios-hwe, necessario per la compatibilità con i sistemi BIOS. All’inizio del ciclo i pacchetti HWE sono sostanzialmente equivalenti alle versioni base, ma nei primi due anni della LTS verranno aggiornati ogni sei mesi per seguire le componenti validate nelle release intermedie di Ubuntu. Gli amministratori potranno quindi mantenere l’infrastruttura su un sistema operativo supportato a lungo e adottare, quando necessario, versioni più recenti dei componenti che dialogano direttamente con processori, acceleratori e dispositivi virtualizzati. La novità amplia la piattaforma presentata con Ubuntu 26.04 LTS, Linux 7.0 e il passaggio definitivo a Wayland, spostando l’attenzione dal desktop alle infrastrutture server e cloud.
Lo stack viene aggiornato ogni sei mesi ma resta facoltativo
Canonical non trasforma Ubuntu 26.04 LTS in una distribuzione rolling. Lo stack base rimane quello predefinito e continua a ricevere correzioni di sicurezza e bug fix senza cambiamenti significativi delle versioni. La variante HWE deve invece essere scelta esplicitamente dagli amministratori che necessitano del supporto a hardware e funzioni più recenti. Gli aggiornamenti seguiranno la cadenza delle release intermedie, ma arriveranno sulla LTS dopo un periodo di validazione, riducendo il rischio di introdurre regressioni nei sistemi di produzione. Dopo Ubuntu 26.10, per esempio, la variante HWE di Ubuntu 26.04 dovrebbe ricevere le stesse generazioni di QEMU, libvirt e firmware utilizzate dalla release semestrale, una volta completati i test previsti dal processo Stable Release Update. Il nuovo strumento ubuntu_virt_helper aiuta a passare dallo stack base a quello HWE e viceversa, gestendo i componenti come un insieme coerente. QEMU, libvirt ed EDK2 non possono infatti essere aggiornati isolatamente senza rischiare incompatibilità tra formato delle macchine, firmware, configurazioni XML e funzionalità esposte dall’hypervisor. Il modello si collega alla rapida evoluzione già mostrata da QEMU 11.0 con nuovi miglioramenti per virtualizzazione, architetture e dispositivi.
Il confidential computing richiede l’avanzamento dell’intero stack
La principale motivazione del nuovo sistema è il confidential computing, tecnologia che protegge i dati anche durante l’elaborazione attraverso ambienti isolati e memoria cifrata direttamente dal processore. Ubuntu 26.04 LTS supporta come host e guest AMD SEV-SNP e Intel TDX, ma le prossime funzioni richiederanno modifiche coordinate a kernel, KVM, QEMU, libvirt, firmware OVMF e sistemi di attestazione. Migrazione live delle macchine riservate, assegnazione sicura dei dispositivi, acceleratori protetti e TDISP non possono essere abilitati intervenendo su un solo componente. Un processore può già offrire la capacità hardware, ma QEMU deve esporla alla macchina virtuale, libvirt deve renderla configurabile e il firmware deve consentire al guest di avviarsi mantenendo la catena di fiducia. Prima dello stack HWE, un’impresa poteva essere costretta a scegliere tra una release intermedia più aggiornata e una LTS con componenti ormai troppo vecchi per il nuovo hardware. Canonical prova ora a eliminare questo compromesso, soprattutto per cloud sovrani, servizi finanziari, sanità e inferenza AI su dati sensibili. Il problema della protezione dei carichi AI era già emerso con gli strumenti di confidential computing sviluppati per rendere più sicura l’intelligenza artificiale aziendale.
Kernel HWE e Virtualization HWE possono essere gestiti separatamente
Canonical consiglia di abbinare lo stack di virtualizzazione al kernel HWE, ma non impone l’utilizzo congiunto delle due componenti. Un amministratore può mantenere il kernel predefinito e aggiornare QEMU e libvirt, oppure adottare il kernel più recente senza modificare lo stack userspace. La separazione offre maggiore flessibilità, ma le funzioni hardware più avanzate possono richiedere versioni compatibili su entrambi i livelli. Le tecnologie di virtualizzazione assistita dipendono infatti dalle interfacce esposte dal kernel e da KVM; installare un QEMU recente non abilita automaticamente una caratteristica assente nel kernel. Al contrario, un nuovo driver o una nuova funzione KVM può restare inutilizzabile quando libvirt ed EDK2 non dispongono ancora del supporto necessario. Le imprese dovranno quindi verificare matrici di compatibilità, procedure di rollback e comportamento delle macchine esistenti prima di migrare lo stack. Il vantaggio del modello Canonical consiste nella disponibilità di un percorso supportato, evitando repository esterni o compilazioni manuali difficili da mantenere durante l’intero ciclo della LTS.
fwupd 2.1.7 amplia i controlli sulla sicurezza del firmware
fwupd 2.1.7 aggiorna il servizio Linux utilizzato per distribuire firmware attraverso LVFS e le interfacce dei produttori. La release aggiunge identificativi AppStream standard per alcune impostazioni BIOS, un attributo di sicurezza dedicato al blocco delle memorie MTD e il supporto alle liste di firme EFI gestite esternamente. Quest’ultima funzione è rilevante negli ambienti nei quali le autorità di certificazione e le chiavi di Secure Boot non vengono amministrate direttamente dal sistema locale. Arriva inoltre un plugin per systemd-pcrlock, collegato agli aggiornamenti UEFI per coordinare le variazioni delle misurazioni TPM con le policy che proteggono dischi e credenziali. Un aggiornamento firmware può infatti modificare i valori registrati nei Platform Configuration Register e impedire lo sblocco automatico di un volume cifrato quando il cambiamento non viene previsto correttamente. La nuova versione introduce anche un attributo basato sulle specifiche TCG per segnalare lo stato della cifratura dei dischi e abilita un numero maggiore di plugin nelle compilazioni destinate ad Android. L’aggiornamento segue fwupd 2.1.6, che aveva già ampliato il supporto hardware e la gestione degli aggiornamenti firmware su Linux.
Metadati fidati e parser più sicuri riducono i rischi di aggiornamento
La release rende obbligatori i metadati fidati per gli aggiornamenti dei dispositivi e rafforza il comportamento dell’opzione OnlyTrusted, riducendo la possibilità che pacchetti non verificati vengano accettati durante la distribuzione del firmware. fwupd 2.1.7 corregge anche potenziali letture fuori dai limiti nei parser DFU, valida gli offset delle sezioni EFI e controlla il valore della modalità dei dispositivi CCGX prima di utilizzarlo per indicizzare le versioni. Sono state risolte inoltre una segmentazione durante l’analisi di alcuni record del bootloader Logitech HID++ e risposte non sicure provenienti dai dispositivi Synaptics RMI. Sul piano operativo vengono corretti gli aggiornamenti del Lenovo TBT5 Smart Dock 7500, gli errori di autenticazione Polkit di fwupd-refresh.service e i mancati aggiornamenti di stato durante l’installazione. La versione aggiunge infine il supporto al dispositivo PixArt PJP360. fwupd resta un componente particolarmente delicato perché opera con privilegi elevati e modifica software eseguito prima del sistema operativo. I miglioramenti proseguono il lavoro già introdotto con fwupd 2.1.2 per rafforzare firmware, privacy e affidabilità dei sistemi Linux, consolidando la catena che collega metadati, firme, Secure Boot, TPM e aggiornamenti distribuiti dai produttori.
Iscriviti alla Newsletter
Non perdere le analisi settimanali: Entra nella Matrice Digitale.
Matrice Digitale partecipa al Programma Affiliazione Amazon EU. In qualità di Affiliato Amazon, ricevo un guadagno dagli acquisti idonei. Questo non influenza i prezzi per te.









