Sebbene ormai non se ne parli quasi più, nella prima parte dell'anno le falle Meltdown e Spectre scoperte nei processori Intel hanno spesso conquistato le prime pagine, a volte terrorizzando gli utenti ben oltre lo stretto necessario.

Anche se la questione non è più strettamente d'attualità, patch e correzioni per risolvere i problemi e contrastare le nuove varianti degli exploit che a mano a mano emergono continuano uscire.

Un caso particolarmente spiacevole è quello che riguarda una patch di recente inserita nella versione 4.20 del kernel di Linux (e, tramite backport, anche nella versione 4.19.2) e riguardante i Single Thread Indirect Branch Predictors (STIBP).

Sullo stesso tema:

Windows 11 25H2 rallenterà per risparmiare batteria

Un intero sistema operativo nascosto nelle CPU

Bug nei processori AMD: a rischio password e crittografia

Intel, le patch per le nuove falle danneggiano seriamente le prestazioni

La correzione svolge il proprio lavoro, ma a caro prezzo: il suo impatto sulle prestazioni è infatti molto pesante.

Sin dall'inizio della vicenda lo spettro di un calo deciso delle prestazioni a seguito dell'installazione delle patch è stato agitato davanti agli occhi degli utenti, ma in generale il fenomeno ha riguardato pochi casi e l'impatto è stato molto limitato.

Questa volta la faccenda è più seria: in base ai test di Phoronix, a seconda delle operazioni condotte e usando l'HyperThreading, un processore debitamente patchato rallenta del 30% o addirittura del 50% rispetto a un processore che lavora senza patch.

La situazione è evidentemente inaccettabile, tanto che Linus Torvalds - nella sua nuova versione libera da intemperanze - è intervenuto suggerendo di disabilitare l'HyperThreading nei processori Intel, operazione che, secondo il padre di Linux, «quanti sono attenti alla sicurezza compiono comunque».

L'alternativa è non attivare la correzione STIBP, considerando che, dopotutto, la possibilità di un attacco tramite la falla che essa corregge è praticamente soltanto teorica ed è estremamente difficile che qualcuno lo conduca per davvero.

Se fosse soltanto per Torvalds, la strada sarebbe chiara: disabilitare la patch nel kernel Linux e lasciare agli utenti che lo vogliano la possibilità di riabilitarla.

«Avvisiamoli una volta» - scrive - «e lasciamo che i pazzi dicano "Preferisco che le prestazioni calino del 50% piuttosto che angosciarmi per un problema teorico».