Come verificare lo stato del TPM da riga di comando

Se devi capire rapidamente se il TPM è davvero operativo, non basta vedere che il chip esiste nel BIOS: serve verificare che il sistema lo esponga correttamente, che il device sia accessibile e che le funzioni base rispondano senza errori. Su Linux, il percorso più pulito passa da tpm2-tools, dal device /dev/tpm0 o /dev/tpmrm0 e da un controllo minimo dei log di boot. L’obiettivo è distinguere tre casi: TPM assente o disabilitato, TPM presente ma non inizializzato dal kernel, TPM presente e funzionante ma con limitazioni di firmware o policy.

Verificare che il kernel veda il TPM

Il primo controllo non riguarda ancora le utility TPM, ma la presenza del dispositivo sul sistema. Se il kernel non crea il device, qualsiasi test successivo è già falsato.

Controlla i nodi disponibili:

ls -l /dev/tpm*

Output atteso, in uno scenario normale: almeno /dev/tpm0 e spesso anche /dev/tpmrm0. Il primo è l’accesso diretto al chip; il secondo è il resource manager del kernel, utile quando più processi condividono il TPM.

Se non compare nulla, il problema è a monte: firmware disattivato, modulo non caricato, oppure dispositivo non enumerato. In quel caso passa ai log del kernel:

dmesg | grep -iE 'tpm|trusted|crb|tis'

Qui cerchi righe che confermino l’inizializzazione del driver TPM, ad esempio riferimenti a tpm_tis, tpm_crb o messaggi di probing dell’hardware. Se trovi errori come timeout, device non rispondente o fallimenti di probing, hai già una pista concreta: il TPM è visto dal firmware ma non è utilizzabile dal kernel.

Controllare i servizi e gli strumenti user space

Su molte distribuzioni il supporto utente arriva tramite tpm2-tools. Senza questo pacchetto puoi avere il TPM perfettamente funzionante ma nessun mezzo comodo per interrogarlo.

Verifica la presenza degli strumenti:

which tpm2_getcap
which tpm2_pcrread
which tpm2_selftest

Se i comandi non esistono, installa il pacchetto della tua distribuzione. Su Debian/Ubuntu il nome è in genere tpm2-tools; su RHEL, AlmaLinux, Rocky e derivate è spesso lo stesso. Qui il dato preciso dipende dal repository abilitato, quindi va verificato con il gestore pacchetti locale.

Se il sistema usa il resource manager, controlla anche che il device dedicato sia presente:

ls -l /dev/tpmrm0

La sua presenza non è obbligatoria, ma è un buon segnale: indica che il kernel sta offrendo l’accesso mediato al TPM, di solito la modalità più comoda e meno soggetta a conflitti tra processi.

Leggere le capability del TPM

Il test più utile, quando vuoi sapere se il TPM risponde davvero, è interrogare le capability esposte dal chip. Se il comando fallisce, non stai più guardando un problema cosmetico: c’è un guasto di accesso, di driver o di firmware.

Esegui:

tpm2_getcap properties-fixed

Se il TPM è sano, ricevi un blocco di proprietà con valori come versione del firmware, dimensione del buffer, supporto agli algoritmi e altre caratteristiche hardware. Non serve memorizzare ogni campo: quello che conta è che il comando risponda senza errori. Un errore di tipo TPM_RC_FAILURE, connection refused o device not found indica un problema reale da investigare.

Puoi spingerti oltre con un controllo più ampio delle capability:

tpm2_getcap -l

Questo elenco mostra le famiglie di capability disponibili. Se il comando risponde correttamente, hai già confermato che la comunicazione base con il chip funziona. Se invece il comando va in timeout o produce errori di accesso, la priorità passa a firmware, BIOS/UEFI e driver kernel.

Fare un self-test senza toccare policy o chiavi

Un self-test è una verifica più diretta, ma va usato con criterio: non modifica chiavi o policy, però può restituire errori utili a capire se il TPM è bloccato da uno stato interno anomalo.

Avvia il test:

tpm2_selftest

Se il comando termina senza errori, il TPM ha superato il controllo interno. Se invece segnala failure, annota con precisione il codice restituito e confrontalo con i log del kernel. In alcuni casi il problema non è nel chip ma nel modo in cui il firmware lo inizializza dopo un reboot caldo, soprattutto su macchine dove il TPM è condiviso con funzioni di Secure Boot o cifratura disco.

Un buon criterio pratico è questo: se tpm2_getcap funziona ma tpm2_selftest no, il percorso di comunicazione è presente ma il TPM non è in uno stato sano. Se falliscono entrambi, il problema è più probabilmente di visibilità del device o di driver.

Leggere i PCR per capire se il TPM è usato dal sistema

I Platform Configuration Registers non servono solo per la sicurezza: sono anche un ottimo indicatore del fatto che il TPM sia integrato nel flusso di boot. Se i PCR sono leggibili, il chip non è solo presente, ma partecipa al trust chain del sistema.

Prova a leggere alcuni registri:

tpm2_pcrread sha256:0,7,11,14

Un output regolare mostra i valori hash dei registri richiesti. Se il comando risponde, hai conferma che il TPM è accessibile e che almeno il set di PCR selezionato è leggibile. Se il comando restituisce un errore, controlla prima se il sistema usa davvero SHA-256 come algoritmo primario; alcuni ambienti storici espongono altre combinazioni, ma oggi SHA-256 è la scelta più comune.

Se vuoi capire se il TPM è coinvolto in misure di boot, incrocia questi dati con il bootloader e con eventuali strumenti di integrità del sistema. Non serve andare oltre se il tuo obiettivo è solo verificare lo stato del chip; ma in ambienti con cifratura disco o attestation, i PCR sono il segnale più interessante.

Distinguere TPM 1.2 e TPM 2.0

Molti problemi nascono da aspettative sbagliate: si pensa di avere un TPM 2.0, ma il firmware espone solo un vecchio 1.2 oppure una modalità compatibile limitata. Prima di fare diagnosi più profonde, conviene leggere la versione supportata.

Usa:

tpm2_getcap properties-fixed | grep -i version

Se il comando mostra campi relativi alla famiglia e alla revisione, puoi capire rapidamente che tipo di TPM hai davanti. In alternativa, alcuni firmware riportano la versione direttamente nel setup UEFI. Il punto non è inseguire un’etichetta, ma sapere se gli strumenti e le policy che vuoi usare sono compatibili con quel chip.

Attenzione a un caso comune: alcune macchine offrono firmware TPM, cioè un’implementazione nel processore o nel firmware della piattaforma, non un modulo fisico separato. Dal punto di vista operativo cambia poco, ma può cambiare il comportamento dopo aggiornamenti BIOS/UEFI o reset delle impostazioni di sicurezza.

Controllare BIOS, UEFI e stato di abilitazione

Se i test da Linux falliscono ma il chip dovrebbe esserci, il passaggio successivo è il firmware di macchina. Qui non c’è un comando universale, perché dipende dal produttore, ma la logica è sempre la stessa: il TPM deve essere abilitato, non disabilitato o nascosto dalla configurazione di sicurezza.

Nei menu UEFI cerca voci come TPM, Security Device, Intel PTT o AMD fTPM. Lo stato atteso è Enabled. Se trovi Disabled, il sistema operativo non avrà un device da interrogare. Dopo il cambio, salva e riavvia, poi ripeti i controlli su /dev/tpm* e tpm2_getcap properties-fixed.

Qui il rollback è semplice: se abiliti il TPM e noti effetti collaterali inattesi, puoi tornare alla configurazione precedente dal firmware. Il blast radius è basso sul sistema operativo, ma non nullo se la macchina usa il TPM per sbloccare disco o per policy di avvio: in quel caso verifica prima la presenza di recovery key o procedure di sblocco alternative.

Leggere i log quando il TPM non risponde

Quando il chip c’è ma non risponde, i log sono il modo più veloce per evitare tentativi a vuoto. Il kernel e i servizi associati registrano spesso il punto esatto del guasto: timeout, reset, mismatch di driver o errori di accesso al bus.

Consulta i messaggi recenti:

journalctl -k -b | grep -iE 'tpm|crb|tis|trusted'

Se trovi righe con timeout, failed, error -110 o simili, il problema può essere transitorio oppure legato a incompatibilità tra firmware e driver. In quel caso vale la pena provare un reboot completo a freddo, perché alcuni TPM embedded si riprendono solo dopo un power cycle reale, non dopo un semplice riavvio.

Se i log sono puliti ma i comandi falliscono, il problema può stare nel layer user space o nei permessi sul device. Verifica i gruppi e i permessi del nodo:

ls -l /dev/tpm0 /dev/tpmrm0

Di norma i permessi sono gestiti da udev e dal gruppo corretto. Se qualcuno ha alterato regole personalizzate, puoi trovarti con un TPM sano ma non accessibile agli utenti previsti.

Checklist operativa rapida

Se vuoi una sequenza breve e ripetibile, questa è la traccia più utile per un controllo da riga di comando:

1. Verifica i device con ls -l /dev/tpm*. Atteso: almeno /dev/tpm0 o /dev/tpmrm0.
2. Controlla i messaggi del kernel con dmesg | grep -iE 'tpm|trusted|crb|tis'. Atteso: init senza errori critici.
3. Interroga le capability con tpm2_getcap properties-fixed. Atteso: output leggibile con proprietà del chip.
4. Esegui un self-test con tpm2_selftest. Atteso: completamento senza errori.
5. Leggi qualche PCR con tpm2_pcrread sha256:0,7,11,14. Atteso: valori hash restituiti.
6. Se qualcosa fallisce, vai nel firmware UEFI e verifica che il TPM sia abilitato.

Quando il risultato non basta a chiudere il problema

Ci sono situazioni in cui il TPM risponde ai comandi base ma il sistema continua a comportarsi male: ad esempio cifratura disco che non si sblocca, attestation che fallisce, o applicazioni che si aspettano una versione o un algoritmo specifico. In quel caso non basta sapere che il chip esiste: serve capire esattamente quale componente lo usa e con quale policy.

Le informazioni minime da raccogliere sono: output di tpm2_getcap properties-fixed, presenza di /dev/tpm0 e /dev/tpmrm0, estratto di journalctl -k -b con i messaggi TPM, e stato nel firmware UEFI. Con questi quattro elementi si separano quasi sempre i casi di hardware assente, driver rotto, firmware disabilitato e incompatibilità applicativa.

Assunzione operativa: sistema Linux recente, TPM 2.0 o compatibile, accesso amministrativo locale, e nessuna policy aziendale che blocchi la lettura dei device TPM da user space.