Anche se molti non ci fanno più caso, o la cosa sembra tutto sommato non più di attualità, le mitigazioni ai bug delle CPU, vedi Heartbleed, Spectre e compagnia cantante, sono ancora silentemente attive su tutte le installazioni GNU/Linux attualmente in circolazione perché, se non fosse chiaro, quei bug non se ne andranno mai.
Ma quali sono le mitigazioni impostate sul proprio sistema?
Il modo più veloce per capirlo è utilizzando un semplice comando, lscpu ed osservando un output che potrebbe essere simile al seguente:
Vulnerabilities:
Gather data sampling: Mitigation; Microcode
Itlb multihit: KVM: Mitigation: VMX disabled
L1tf: Not affected
Mds: Not affected
Meltdown: Not affected
Mmio stale data: Mitigation; Clear CPU buffers; SMT vulnerable
Reg file data sampling: Not affected
Retbleed: Mitigation; Enhanced IBRS
Spec rstack overflow: Not affected
Spec store bypass: Mitigation; Speculative Store Bypass disabled via prctl
Spectre v1: Mitigation; usercopy/swapgs barriers and __user pointer sanitization
Spectre v2: Mitigation; Enhanced / Automatic IBRS; IBPB conditional; RSB filling; PBRSB-eIBRS SW sequence; BHI SW loop, KVM SW loop
Srbds: Mitigation; Microcode
Tsx async abort: Mitigation; TSX disabledQuesto elenco trova il suo corrispettivo anche all’interno del filesystem virtuale /sys, precisamente qui:
$ grep . /sys/devices/system/cpu/vulnerabilities/*
/sys/devices/system/cpu/vulnerabilities/gather_data_sampling:Mitigation: Microcode
/sys/devices/system/cpu/vulnerabilities/itlb_multihit:KVM: Mitigation: VMX disabled
/sys/devices/system/cpu/vulnerabilities/l1tf:Not affected
/sys/devices/system/cpu/vulnerabilities/mds:Not affected
/sys/devices/system/cpu/vulnerabilities/meltdown:Not affected
/sys/devices/system/cpu/vulnerabilities/mmio_stale_data:Mitigation: Clear CPU buffers; SMT vulnerable
/sys/devices/system/cpu/vulnerabilities/reg_file_data_sampling:Not affected
/sys/devices/system/cpu/vulnerabilities/retbleed:Mitigation: Enhanced IBRS
/sys/devices/system/cpu/vulnerabilities/spec_rstack_overflow:Not affected
/sys/devices/system/cpu/vulnerabilities/spec_store_bypass:Mitigation: Speculative Store Bypass disabled via prctl
/sys/devices/system/cpu/vulnerabilities/spectre_v1:Mitigation: usercopy/swapgs barriers and __user pointer sanitization
/sys/devices/system/cpu/vulnerabilities/spectre_v2:Mitigation: Enhanced / Automatic IBRS; IBPB: conditional; RSB filling; PBRSB-eIBRS: SW sequence; BHI: SW loop, KVM: SW loop
/sys/devices/system/cpu/vulnerabilities/srbds:Mitigation: Microcode
/sys/devices/system/cpu/vulnerabilities/tsx_async_abort:Mitigation: TSX disabledCome si nota dai vari output oltre ai soliti noti ci sono tanti altri nomi e riferimenti di cui verosimilmente non si è mai sentito parlare, ma per tutte le voci che recitano Mitigation vuol dire che in quel caso la fix è stata applicata nel sistema. Per fare la prova inversa basterebbe impostare l’opzione di boot mitigations=off ed osservare tutte le voci diventare Vulnerable, guadagnando al contempo dal 10% al 20% di performance in più nel proprio sistema.
L’approccio usato in questo caso è in modalità “tutti o nessuno”, ed in ogni caso orientarsi in tutto il marasma delle voci e dei nomi è sicuramente complicato, ma potrebbe esistere un modo per rendere le cose più semplici?
A risolvere questa problematica ci sta pensando David Kaplan, un ingegnere AMD che ha proposto una serie (piuttosto ampia) di patch allo scopo di inserire nuove opzioni a linea di comando per regolare e gestire le mitigazioni applicate alle CPU.
Nel messaggio di presentazione delle prime 18 patch il lavoro viene presentato come segue:
This series restructures arch/x86/kernel/cpu/bugs.c and proposes new command line options to make it easier to control which CPU mitigations are applied. These options select relevant mitigations based on chosen attack vectors, which are hopefully easier for users to understand.
Questa serie ristruttura arch/x86/kernel/cpu/bugs.c e propone nuove opzioni a riga di comando per rendere più semplice il controllo di quali mitigazioni della CPU vengono applicate. Queste opzioni selezionano mitigazioni pertinenti basate su vettori di attacco scelti, che si sperano più facili da capire per gli utenti.
Quindi il criterio è semplice: sulla base dei vettori di attacco conosciuti sarà possibile impostare quali mitigazioni inserire.
Ed ancora:
While many users may not be intimately familiar with the details of these CPU vulnerabilities, they are likely better able to understand the intended usage of their system. As a result, unneeded mitigations may be disabled, allowing users to recoup more performance.
New documentation is included with recommendations on what to consider when choosing which attack vectors to enable/disable.Sebbene molti utenti potrebbero non avere familiarità con i dettagli di queste vulnerabilità della CPU, sono probabilmente in grado di comprendere meglio l’uso previsto del loro sistema. Di conseguenza, le mitigazioni non necessarie possono essere disabilitate, consentendo agli utenti di recuperare maggiori prestazioni. La nuova documentazione è inclusa con le raccomandazioni su cosa considerare quando si sceglie quali vettori di attacco abilitare/disabilitare.
Pensiero totalmente condivisibile che viene incontro a quell’esigenza di consapevolezza che normalmente gli utenti GNU/Linux vogliono.
Non è ancora chiaro quando le patch arriveranno nel kernel Linux, magari già con la prossima versione 6.14, quello che è certo è che queste modifiche saranno più che benvenute!
Raoul Scarazzini
Da sempre appassionato del mondo open-source e di Linux nel 2009 ho fondato il portale Mia Mamma Usa Linux! per condividere articoli, notizie ed in generale tutto quello che riguarda il mondo del pinguino, con particolare attenzione alle tematiche di interoperabilità, HA e cloud.
E, sì, mia mamma usa Linux dal 2009.
Source: Read More
