Arch Linux: mkinitcpio 42 richiede intervento manuale con TPM2 e LUKS

🐧 Novità principali

• mkinitcpio 42-1 aggiunge systemd-pcrosseparator.service all’hook systemd e modifica le misurazioni di numerosi Platform Configuration Register del TPM.
• L’intervento riguarda le installazioni LUKS sbloccate tramite TPM2 e vincolate ai PCR interessati, non genericamente tutti gli utenti Arch Linux.
• Arch raccomanda di ripetere l’enrollment TPM2 prima del riavvio oppure aggiornare le policy pcrlock utilizzate dal sistema.

Arch Linux richiede un intervento manuale a una parte degli utenti che aggiornano a mkinitcpio 42-1 e utilizzano il TPM2 per sbloccare automaticamente volumi LUKS. Non si tratta di una vulnerabilità, di una regressione della cifratura o di un problema che coinvolge indiscriminatamente tutte le installazioni Arch: la modifica nasce dall’integrazione di systemd-pcrosseparator.service nell’hook systemd di mkinitcpio e cambia il valore misurato in diversi Platform Configuration Register. Le macchine sulle quali una chiave LUKS è stata legata proprio a quei PCR possono quindi non riconoscere più lo stato atteso dopo l’aggiornamento. Il rischio operativo è semplice: effettuare l’upgrade e riavviare senza aggiornare l’enrollment può lasciare inutilizzabile lo sblocco automatico tramite TPM2, costringendo a ricorrere alla passphrase o alle procedure di recovery disponibili.

mkinitcpio 42 cambia le misurazioni che il TPM usa per fidarsi del boot

L’avviso ufficiale pubblicato da Arch Linux riguarda il pacchetto mkinitcpio 42-1. Con questa versione l’hook systemd include systemd-pcrosseparator.service, componente previsto da systemd 261 per separare in maniera più esplicita le differenti fasi delle misurazioni PCR. La conseguenza è una modifica dei valori dei PCR da 0 a 7, del PCR 9 e dei PCR da 12 a 14. In un sistema che usa TPM2 soltanto come componente hardware ma non lega lo sblocco LUKS a questi valori non cambia necessariamente nulla; il problema appare quando l’enrollment della chiave è stato costruito assumendo che determinati PCR conservassero le misurazioni precedenti. Dopo l’aggiornamento quel confronto può fallire perché il TPM vede un boot differente dal punto di vista crittografico, anche se kernel, initramfs e disco non sono stati compromessi. Il cambio arriva poche settimane dopo l’adozione di Linux 7.2 nella nuova ISO mensile di Arch Linux, confermando la natura della rolling release: l’utente riceve rapidamente i cambiamenti upstream, ma alcune modifiche profonde del boot richiedono attenzione prima del riavvio.

Leggi anche: Linux 7.1 raggiunge l’EOL e lascia spazio al ramo Linux 7.2

Chi utilizza systemd-cryptenroll deve ripetere l’enrollment del TPM2

Arch indica una procedura differente in base al metodo utilizzato per vincolare la chiave. Chi usa PCR fissati direttamente attraverso systemd-cryptenroll deve procedere a un nuovo enrollment seguendo la documentazione ufficiale di systemd-cryptenroll o la guida ArchWiki dedicata. In termini operativi significa rimuovere o sostituire lo slot TPM2 configurato in precedenza e registrare nuovamente il volume quando il sistema utilizza già le nuove misurazioni. La passphrase o un’altra chiave di recovery non devono quindi essere considerate opzionali durante questo passaggio: prima di modificare gli slot LUKS è necessario verificare di possedere un metodo alternativo funzionante per aprire il volume. La precisazione è importante perché TPM2 non contiene normalmente la chiave LUKS in chiaro pronta per essere restituita a qualsiasi boot. Lo sblocco può essere subordinato allo stato misurato della piattaforma. I PCR rappresentano proprio una parte di questo stato e cambiano quando determinati elementi della catena di avvio vengono misurati diversamente. L’aggiornamento di mkinitcpio non rende meno sicura la cifratura: rende semplicemente non più valida una policy costruita sulle vecchie misurazioni. È lo stesso genere di dipendenza profonda tra kernel, initramfs e boot che rende gli aggiornamenti delle distribuzioni rolling molto differenti dal semplice aggiornamento di un’applicazione desktop.

pcrlock richiede attenzione alle policy personalizzate

Arch separa inoltre il caso degli utenti che utilizzano systemd-pcrlock. Se lo sblocco dipende da policy personalizzate e systemd-pcrlock-make-policy.service è stato disabilitato, occorre consultare la documentazione ufficiale di systemd-pcrlock e rigenerare coerentemente la policy. pcrlock è stato progettato proprio per rendere più gestibili le variazioni ammesse della catena di boot rispetto al semplice pinning rigido di singoli PCR, ma una policy generata in precedenza non può essere data per valida quando cambia il modo in cui systemd misura le fasi dell’avvio. Il contesto tecnico si collega alla progressiva adozione di systemd anche nelle fasi precedenti al mount del filesystem principale. La trasformazione era già visibile nel passaggio di NixOS a systemd come initrd predefinito: spostare più logica nell’initramfs migliora integrazione e uniformità degli strumenti, ma rende ancora più importante comprendere quali componenti partecipino al trust del boot. Con TPM2 e cifratura automatica, una modifica apparentemente interna a systemd può diventare immediatamente visibile al meccanismo che decide se consegnare o meno il segreto necessario ad aprire il disco.

Continua con:

Analisi tecnica di Linux Kernel 7.1 tra filesystem, sicurezza e hardware

MX Linux 25.3 porta Linux 7.2 nell’edizione Advanced Hardware Support

Il punto critico è aggiornare prima di riavviare

La sequenza delle operazioni conta più della gravità apparente dell’aggiornamento. Un sistema già avviato dispone normalmente dell’accesso ai volumi e permette di correggere l’enrollment con relativa semplicità; scoprire il problema soltanto al boot successivo significa invece trovarsi davanti a un volume che il TPM rifiuta di sbloccare automaticamente. Chi possiede una passphrase LUKS valida può comunque recuperare l’accesso e sistemare la configurazione, mentre una macchina progettata facendo affidamento esclusivo sullo sblocco TPM senza una procedura di recovery accessibile può trasformare un aggiornamento ordinario in un problema operativo serio. La raccomandazione di Arch va quindi letta in modo preciso: non bisogna evitare mkinitcpio 42, ma verificare prima dell’upgrade se il sistema utilizza l’hook systemd, TPM2, LUKS e PCR interessati dalla nuova misurazione. In quel caso enrollment o policy devono essere aggiornati prima del riavvio. È uno dei classici casi nei quali la rolling release non “rompe” genericamente il sistema: porta rapidamente un cambiamento upstream corretto, ma obbliga chi ha costruito una catena di boot crittograficamente vincolata a riallineare la propria policy di fiducia.