Äskettäin Linux Kernel Development Leader Linus Torvalds ehdotti STIBP-laastareiden aktivoinnin mekanismin tarkistamista (Single Thread Indirect Branch Predictors), jotka tarjoavat lisäsuojaa Spectre v2: ta vastaan.
Nämä korjaustiedostot on äskettäin sisällytetty Linux-ytimen haaraan 4.20 kehitteillä ja ne on viety uudelleen Linux-ytimen 4.19.2 vakaan versioon.
Käyttämällä STIBP: tä sen nykyisessä muodossa käyttäjät huomasi joidenkin sovellusten suorituskyvyn merkittävän heikkenemisen käytettäessä tätä samanaikaista monisäikeistä tekniikkaa (SMT tai Hyper-Threading).
Dado que suorituskyvyn pudotus voi saavuttaa 50%, itse Linus Torvaldsin sanoin, STIBP: n käyttö nykyisessä muodossaan on merkityksetöntäkoska on helpompaa ja luotettavampaa poistaa SMT / Hyper-Threading kokonaan käytöstä, mitä tietoturvatietoiset ihmiset usein tekevät.
Suurin hidastus, jonka uuden Linux 4.20 -ydin aiheuttaa, johtuu Spectre-version 2 lieventämisestä että Linuxin perustaja Linus Torvalds haluaa nyt rajoittaa.
Tällöin herää kysymys, onko tarpeen ottaa STIBP käyttöön oletusarvoisesti, kun SMT / Hyper-Threading on jo poistettu käytöstä niille, jotka todella välittävät turvallisuudesta.
Sillä aikaa, Normaalille käyttäjälle 50%: n suorituskyvyn menetys on merkittävä tekijä, joka voi edustaa joitain ongelmia ja On kyseenalaista, ovatko nämä teoreettiset haavoittuvuudet estettävissä.
Torvalds edellyttää, että STIBP ei ole enää oletusarvoisesti käytössä
Omalta Linus Torvalds katsoo, että Spectre v2: een perustuvia käytännön hyökkäyksiä ei todennäköisesti esiinny tavallisiin käyttäjäjärjestelmiin.
Linus Torvalds väittää, että selaimet ovat hyökkäysten pääkohde, mikä on jo lisännyt suojaa tasolleen (uhka on eristetyille JIT-prosesseille, joille voidaan kehittää valikoiva suojausmenetelmä).
Se ehdottaa, että oletusarvoisesti käytetään vain Spectre-suojausmenetelmiä, jotka eivät johda suureen suorituskyvyn heikkenemiseen, vaan käyttävät lisämenetelmiä valikoivasti tai vaihtoehtona.
Joten miksi STIBP hidastuu oletusarvoisesti, kun ihmiset, jotka * todella * huolehtivat, poistavat jo SMT: n käytöstä?
Mielestäni meidän pitäisi käyttää samaa logiikkaa kuin L1TF: ssä - oletusarvoisesti emme voi poistaa suorituskykyä. Ilmoita asiasta kerran ja anna hullujen sanoa "Minulla on mieluummin 50%: n onnistumisaste kuin huolehdin teoreettisesta ongelmasta." Linus torvalds
STIBP: n oletuskäyttö tulee palauttaa
Lisäksi, Intelin Arjan van de Ven sanoi, että Intel ja AMD eivät suosittele STIBP: n käyttöä oletuksena että tätä toimintoa voidaan verrata erittäin raskaaseen vasaraan, koska sitä ei käytetä päivittäisessä työssä, mutta se on välttämätöntä tietyissä olosuhteissa.
Hän väittää sen mikrokoodipäivityksessä ehdotettu STIBP-mekanismi antaa sinun hallita prosessorin välimuistien sammumista asettamalla erityinen bitti CR0-rekisteriin, jota ei pitäisi tehdä kaikkialla, mutta vain erityisen kriittisissä tilanteissa.
Intelin Tim Chen ehdotti, että hiekkalaatikkohyökkäysten valikoiva esto sisältäisi STIBP: n vain silloin, kun sitä nimenomaisesti pyydetään prctl: n kautta tai prosesseille, jotka kieltävät ydinjätteiden (PR_SET_DUMPABLE) luomisen, kuten sshd.
Mitä tulee suorituskyvyn pudotukseen käytettäessä STIBP-korjauksia Linux Kernel 4.20: ssa, tulos riippuu suurelta osin kuormitustyypistä.
Esimerkiksi tehdyt testit ovat osoittaneet, että SpecInt Rate 2006 -paketin suorituskyvyn heikkeneminen on 21%, kun taas Phoronix-testien suorituskyvyn heikkeneminen on 3% - 20%.
Ingo Molnar, tunnettu Linux-ytimen kehittäjä ja CFS Task Scheduler -sovelluksen kirjoittaja, ehdotti tilannetta kommentoidessaan suorituskykytestitietojen muutosluettelon lisäämistä, kun ongelmiin lisätään ratkaisuja.