Cosa mostra effettivamente la sezione "bug" di / proc / cpuinfo?

Su un sistema Debian Stretch e testing / Buster con un kernel corrente e un microcodice installato vedo ancora il tracollo e lo spettro elencati come bug in /proc/cpuinfo.

Tuttavia, l'esecuzione degli spectre-meltdown-checkerspettacoli non è vulnerabile.

Quindi mi chiedo cosa /proc/cpuinfo mostri. Queste sono solo le vulnerabilità di questa CPU e saranno sempre elencate nonostante abbiano un sistema patchato?

linux cpu proc

— hurrbert
fonte

Risposte:

L'intento del campo "bug" in /proc/cpuinfoè descritto nel messaggio di commit che lo ha introdotto :

x86/cpufeature: Aggiungi flag bug a /proc/cpuinfo

Scarica i flag che indicano che abbiamo rilevato e / o che hanno applicato soluzioni alternative ai bug sulla CPU su cui stiamo eseguendo, in modo simile ai flag di funzionalità.

Il vantaggio è che quelli non si accumulano nel tempo come le funzionalità della CPU.

In precedenza, i bug hardware rilevati dal kernel erano elencati come funzioni separate ( ad esempio il famigerato bug F00F, che ha la sua f00f_bugvoce /proc/cpuinfosu sistemi x86 a 32 bit). La voce "bugs" è stata introdotta per tenerli in una singola funzione andando avanti, nello stesso stile dei flag CPU x86 .

Per quanto riguarda in pratica le voci, come puoi vedere nel messaggio, tutto ciò che è garantito è che il kernel ha rilevato un bug hardware. Dovrai cercare altrove (messaggi di avvio o /procvoci specifiche o /sysvoci come i file in /sys/devices/system/cpu/vulnerabilities/) per determinare se i problemi vengono risolti.

L'utilità delle voci "bug" è limitata in due modi. Il primo è che i veri negativi non possono essere distinti dagli sconosciuti: se il campo non specifica "cpu_meltdown", non puoi sapere (solo dal campo) se ciò significa che il kernel non è a conoscenza di Meltdown, o che la tua CPU non è influenzata da Meltdown. Il secondo è che il rilevamento può essere troppo semplicistico; è errato dal lato della cautela, quindi potrebbe segnalare che la tua CPU è vulnerabile quando non lo è. Poiché il "rilevamento" è guidato da una tabella, la sua precisione dipende dalla versione del kernel in esecuzione.

Nel caso di bug Meltdown e Spectre, il processo di rilevamento che alimenta i valori /proc/cpuinfo funziona come segue , su x86:

se la CPU non esegue alcuna speculazione (classe 486, alcune di classe Pentium, alcuni di atomi), non è contrassegnata come influenzata da Meltdown o Spectre;
tutte le CPU rimanenti sono contrassegnate come interessate dalle varianti Spectre 1 e 2 (indipendentemente dalla revisione del microcodice ecc.);
se la CPU non è elencata come non suscettibile al bypass speculativo del negozio , se il suo microcodice non pretende di mitigare SSB e se la CPU non afferma di mitigare SSB, allora viene contrassegnato come interessato da SSB;
se la CPU non è elencata come non sensibile a Meltdown (AMD) e se il suo microcodice non afferma di mitigare Meltdown, viene contrassegnato come interessato da Meltdown.

— Stephen Kitt
fonte

Nel caso dello spettro e del crollo non vengono nemmeno rilevati ma solo ipotizzati . Ho un x86 in ordine che non è influenzato da nessuno dei due, ma il kernel riporta che lo è comunque a causa di una regola hardcoded che sostanzialmente dice "qualsiasi CPU Intel più vecchia di X senza una patch di microcodice applicata è vulnerabile al tracollo".

— R ..

@R .. la tua CPU è inclusa nelle tabelle degli ordini nel kernel? (Cerca "cpu_no_speculation" qui per vedere le ultime tabelle.) Questo è davvero uno dei problemi con la voce "bug" wrt. Meltdown, Spectre e altri, la sua accuratezza dipende davvero da quanto è recente il kernel dal momento che il loro "rilevamento" è guidato dalla tabella.

— Stephen Kitt,

No, è un Centerton Bonnell e manca da lì. Vedrò di inviare una patch.

— R ..

Qualcuno sa se questo è ancora corretto quando sono stati applicati gli aggiornamenti del microcodice durante l'avvio ma dopo aver caricato il kernel?

— Bachsau,

Le vulnerabilità di Meltdown / Spectre riguardano il design / l'architettura del chipset della CPU e, a meno di acquistare un nuovo hardware futuro, le patch sono una bella illusione di sicurezza a lungo termine . Nuovi metodi di sfruttamento dei difetti potrebbero emergere nel tempo in grado di bypassare le patch attuali.

In breve, le attuali patch software / microcodice si attenuano i problemi rispetto ai metodi noti della famiglia di exploit Spectre / Meltdown, ma non risolvono i problemi di progettazione della CPU che li consentono in primo luogo. Le CPU (diverse generazioni) interessate non hanno smesso di essere vulnerabili a lungo termine (e molto probabilmente non lo faranno mai).

Tuttavia, come afferma correttamente @Gilles, avere quell'avvertimento non significa che gli attuali exploit conosciuti funzioneranno con i metodi Spectre / Meltdown; non funzioneranno se le patch sono installate.

Nel caso menzionato nella domanda, il kernel sta verificando solo i modelli di CPU noti per essere interessati da Spectre / Meltdown (per ora tutte le CPU x86 se stiamo parlando solo di x86), e quindi il fatto che è cpu-insecureancora elencato nella sezione bug / line in /proc/cpuinfo.

Vai a controllare il tuo /proc/cpuinfo. Conterrà cpu_insecure se il tuo kernel ha la patch KPTI

Ho scoperto che la patch KPTI ha questo pezzo di codice:
   /* Assume for now that ALL x86 CPUs are insecure */
   setup_force_cpu_bug(X86_BUG_CPU_INSECURE);
E dopo l'aggiornamento del kernel, ottieni:
bugs      : cpu_insecure

PS. C'era già una serie di aggiornamenti per un nuovo metodo per sfruttare i "bug" di Spectre / Meltdown. Probabilmente non sarà l'ultima volta.

— Rui F Ribeiro
fonte

ad es. se riesci a trattenere l'acquisto di hw per un po ', aspetta una nuova generazione di CPU. La mia sfera di cristallo mi dice che a medio termine avremo molti server di seconda mano che vendono arachidi.

— Rui F Ribeiro,

I bug della CPU sono elencati /proc/cpuinfoanche se sono completamente mitigati da una patch software. La loro presenza non significa che il tuo sistema sia vulnerabile a quel particolare bug.

— Gilles 'SO- smetti di essere malvagio' il

@Gilles concesso, non sarai in grado di applicare exploit noti. Tuttavia, avevamo già una serie di exploit attorno alla prima generazione di patch, e mi sarei osato dire che molti interessi commerciali là fuori hanno messo a tacere i critici di questo essere un difetto di progettazione fondamentale che costringerà una grande riprogettazione della CPU.

— Rui F Ribeiro,

Questo è vero per gli exploit di tipo Spettro / Meltdown, sono problemi di progettazione fondamentali che continueranno a dare. Ma hai scritto che questo è vero per quanto riguarda la bugslinea e questo è semplicemente sbagliato. La maggior parte dei bug di progettazione della CPU ha una soluzione software completa che costa solo poche prestazioni. Se il kernel applica la soluzione alternativa, il bug è innocuo.

— Gilles 'SO- smetti di essere malvagio' il

@Rui oh, penso di non essermi espresso abbastanza chiaramente - intendevo che l'articolo non rispondeva alla domanda posta dal suo stesso titolo, non che non rispondesse a questa domanda ;-). (Come in, il titolo dell'articolo è "Come il bug Spectre del settore è rimasto segreto per sette mesi", ma l'articolo non spiega come IMO.)

— Stephen Kitt,