Recentment el líder d'al desenvolupament de el nucli de Linux Linus Torvalds va proposar revisar el mecanisme per activar els pegats STIBP (Predictors de branca indirecta de fil únic), que ofereixen protecció addicional contra les vulnerabilitats de classe Spectre v2.
Aquests pegats s'han inclòs recentment en la branca de el nucli de Linux 4.20 en desenvolupament i s'han tornat a exportar a la versió estable de el nucli de Linux 4.19.2.
A l'usar STIBP en la seva forma actual, els usuaris van notar una disminució significativa en el rendiment d'algunes aplicacions a l'usar aquesta tecnologia de subprocessos múltiple simultània (SMT o Hyper-Threading).
atès que la caiguda de l'rendiment pot arribar a assolir el 50%, Segons a paraules de el propi Linus Torvalds, l'ús de STIBP en la seva forma actual no té sentit, Ja que és més fàcil i més fiable desactivar SMT / Hyper-Threading per complet, el que les persones conscients de la seguretat solen fer.
La major desacceleració causada pel nou nucli de Linux 4.20 es deu a una mitigació per a la variant 2 de Specter que el fundador de Linux, Linus Torvalds, ara vol restringir.
Aquí és quan sorgeix la pregunta de si que és necessari habilitar el STIBP de defecte, quan SMT / Hyper-Threading ja està deshabilitat per a aquells que realment es preocupen per la seguretat.
Mentre que, per majoria de gent, una pèrdua de rendiment de l'50% és un factor significatiu que pot representar algunes qüestions i que és dubtós que valgui la pena bloquejar aquestes vulnerabilitats teòriques.
Torvalds exigeix que STIBP ja no s'habiliti per defecte
Per la seva banda Linus Torvalds considera que és poc probable que sorgeixin atacs pràctics basats en Spectre v2, ja que, en els sistemes d'usuaris normals.
Linus Torvalds argumenta que els navegadors són l'objectiu principal dels atacs, que ja han afegit protecció al seu nivell (l'amenaça és per a processos JIT aïllats per als quals es pot desenvolupar un mètode de protecció selectiva).
Se proposa utilitzar per defecte només els mètodes de protecció de Spectre, que no condueixen a una gran caiguda en el rendiment, sinó que utilitzen mètodes addicionals de forma selectiva o com a opció.
Llavors, per què aquest STIBP s'alenteix per defecte quan les persones que * realment * es preocupen ja desactiven el SMT?
Crec que hauríem de fer servir la mateixa lògica que per L1TF: per defecte, no podem eliminar el rendiment. Avisi un cop a l'respecte i deixeu que els bojos diguin «Prefereixo tenir un 50% d'èxit en lloc de preocupar-me per una qüestió de teoria». Linus Torvalds
L'ús predeterminat de STIBP s'ha de revertir
D'altra banda, Arjan van de Ven, d'Intel, va dir que per la part d'Intel i AMD no recomanen l'ús de STIBP per defecte, ja que aquesta funcionalitat pot comparar-se amb un martell molt pesat, atès que no es fa servir en el treball diari, però és necessari en certes circumstàncies.
L'argumenta que el mecanisme STIBP proposat en l'actualització de l'microcodi li permet controlar l'apagat de les memòries cau de l'processador mitjançant la configuració d'un bit especial en el registre CR0, que no s'ha de fer a tot arreu, però només en situacions particularment crítiques.
Tim Chen d'Intel, va proposar que el bloqueig selectiu dels atacs d'espai aïllat incloguin a STIBP només quan aquest se sol·liciti explícitament mitjançant prctl o per a processos que prohibeixin la creació d'bolcats de memòria central (PR_SET_DUMPABLE), com sshd.
Pel que fa a la caiguda de l'rendiment quan s'usen pegats STIBP en el nucli de Linux 4.20, el resultat depèn en gran mesura de l'tipus de càrrega.
Per exemple, les proves que s'han realitzat han demostrat que en el paquet SpecInt Rate 2006 mostren una reducció en el rendiment de l'21%, mentre que les proves de Phoronix mostren una degradació de l'rendiment des del 3% fins a un 20%.
Ingo Molnar un molt conegut desenvolupador de el nucli de Linux i autor de el programador de tasques de CFS, comentant la situació, va suggerir que es afegiu la llista de canvis en la informació de proves de rendiment quan s'agreguin solucions als problemes.