Recent, Linux Kernel Development Leader Linus Torvalds a propus să revizuiască mecanismul de activare a patch-urilor STIBP (Predictori de ramuri indirecte cu un singur fir), care oferă protecție suplimentară împotriva Spectre v2.
Aceste patch-uri au fost recent incluse în ramura kernel-ului Linux 4.20 în curs de dezvoltare și au fost reexportate în versiunea stabilă a nucleului Linux 4.19.2.
Utilizând STIBP în forma sa actuală, utilizatorii am observat o scădere semnificativă a performanței unor aplicații atunci când utilizați această tehnologie simultană multi-threading (SMT sau Hyper-Threading).
dat fiind faptul că scăderea performanței poate ajunge la 50%, în cuvintele lui Linus Torvalds însuși, utilizarea STIBP în forma sa actuală nu are sensdeoarece este mai ușor și mai fiabil să dezactivați complet SMT / Hyper-Threading, ceea ce fac adesea oamenii conștienți de securitate.
Cea mai mare încetinire cauzată de noul kernel Linux 4.20 se datorează unei atenuări pentru varianta Spectre 2 că fondatorul Linux Linus Torvalds vrea acum să restricționeze.
Acesta este momentul în care apare întrebarea dacă este necesar să activați STIBP în mod implicit, când SMT / Hyper-Threading este deja dezactivat pentru cei cărora le pasă cu adevărat de securitate.
In timp ce, Pentru utilizatorii normali, o pierdere de performanță de 50% este un factor semnificativ care poate explica anumite probleme și că este îndoielnic faptul că aceste vulnerabilități teoretice merită blocate.
Torvalds necesită ca STIBP să nu mai fie activat în mod implicit
Între timp Linus Torvalds consideră că este puțin probabil ca atacurile practice bazate pe Spectre v2 să apară ca și pe sistemele normale de utilizator.
Linus Torvalds susține că browserele sunt principala țintă a atacurilor, care au adăugat deja protecție la nivelul lor (amenințarea este pentru procesele JIT izolate pentru care se poate dezvolta o metodă de protecție selectivă).
Se propune să utilizeze în mod implicit numai metodele de protecție Spectre, care nu duc la o scădere mare a performanței, ci folosesc în schimb metode suplimentare selectiv sau ca opțiune.
Deci, de ce acel STIBP încetinește în mod implicit atunci când persoanele cărora * chiar le pasă deja dezactivează SMT?
Cred că ar trebui să folosim aceeași logică ca și pentru L1TF - în mod implicit nu putem elimina performanța. Avertizați o dată despre asta și lăsați-i pe nebuni să spună „Aș prefera o rată de succes de 50% decât să vă îngrijorați de o problemă teoretică” Linus torvalds
Utilizarea implicită a STIBP ar trebui anulată
În plus, Arjan van de Ven al Intel a spus că Intel și AMD nu recomandă utilizarea STIBP în mod implicit, deoarece că această funcționalitate poate fi comparată cu un ciocan foarte greu, deoarece nu este utilizată în munca de zi cu zi, ci este necesară în anumite circumstanțe.
El susține că mecanismul STIBP propus în actualizarea microcodului vă permite să controlați oprirea cache-urilor procesorului prin setarea unui bit special în registrul CR0, care nu trebuie făcut peste tot, ci doar în situații deosebit de critice.
Tim Chen de la Intel a propus ca blocarea selectivă a atacurilor sandbox să includă STIBP numai atunci când este solicitat în mod explicit prin prctl sau pentru procesele care interzic crearea de memorie de bază (PR_SET_DUMPABLE), cum ar fi sshd.
În ceea ce privește scăderea performanței la utilizarea patch-urilor STIBP pe Linux Kernel 4.20, rezultatul depinde în mare măsură de tipul de încărcare.
De exemplu, testele efectuate au arătat că pachetul SpecInt Rate 2006 arată o reducere a performanței de 21%, în timp ce testele Phoronix arată o degradare a performanței de la 3% la 20%.
Ingo Molnar, un cunoscut dezvoltator Linux Kernel și autor al CFS Task Scheduler, comentând situația, a sugerat adăugarea listei de schimbare a informațiilor de testare a performanței atunci când se adaugă soluții la probleme.