Delle vulnerabilità Spectre e Meldown, relative alle CPU Intel, ne stiamo parlando ormai da più di un anno. Scenari apocalittici e momenti di panico hanno attraversato la testa di ciascuno di noi, ma ora che i tempi sono più tranquilli è possibile fare un bilancio effettivo.

Quanti attacchi di vasta scala sono stati riconducibili a queste falle? Apparentemente zero, o almeno noi di MMUL non ne siamo al corrente.

Rimane però il fatto che le mitigazioni a questi problemi sono state da subito oggetto di dibattito: in quanto non rimovibile dalla CPU stessa, il problema è stato gestito via software, eliminando la possibilità di utilizzare la funzionalità che scatena il problema. Funzionalità che però garantiva una maggiore velocità di esecuzione dei processi. Risultato? Un generale, e naturale, rallentamento.

Ma se il problema di fatto sembra non sfruttabile o facilmente arginabile con limitazioni di altro tipo, ha ancora senso mantenere le mitigazioni e scadere nelle performance?

La risposta pare sia no, o quantomeno, è nata da subito l’esigenza di rendere l’abilitazione e disabilitazione delle mitigazioni controllabile dall’utente. Come spiega Catalin Cimpanu di ZDNet, dal kernel 4.15 è possibile disabilitare le mitigazioni mediante l’aggiunta del parametro nospectre_v2 alla command line di esecuzione del Kernel. Dal Kernel 4.17 è addirittura possibile disabilitare tutte le mitigazioni relative a Spectre V4 con l’opzione nospec_store_bypass_disable mentre dal 4.19 l’opzione nospectre_v1 fa la stessa cosa per la versione relativa.

L’articolo continua descrivendo altre nuove modalità di disabilitazione come l’aggiunta di un control bit denominato PR_SPEC_DISABLE_NOEXEC che consentirà ai processi figlio di non subire le limitazioni imposte al processo padre.

Ora, l’intera vicenda porta a domandarsi: che sia stato fatto molto rumore per nulla? O è sempre bene andarci cauti e lasciare tutte le mitigazioni al posto onde evitare spiacevoli sorprese? La scelta come sempre (e per fortuna, aggiungerei) è lasciata a chi i sistemi li deve gestire.

Dura la vita del sistemista, ragazzi.