Nemrégiben a Linux kernel fejlesztési vezetője Linus Torvalds javasolta az STIBP tapaszok aktiválásának mechanizmusának felülvizsgálatát (Single Thread Indirect Branch Predictors), amelyek további védelmet nyújtanak a Spectre v2 ellen.
Ezek a javítások a közelmúltban kerültek be a Linux kernel 4.20 ágába fejlesztés alatt állnak, és újra exportálták őket a Linux kernel 4.19.2 stabil verziójába.
Azáltal, hogy a STIBP-t a jelenlegi formájában használja, a felhasználók egyes alkalmazások teljesítményének jelentős csökkenését észlelte ha ezt az egyidejű többszálas technológiát (SMT vagy Hyper-Threading) használja.
feltéve, hogy a teljesítmény csökkenése elérheti az 50% -ot, maga Linus Torvalds szavaival élve, A STIBP jelenlegi formájában való használata értelmetlenmivel egyszerűbb és megbízhatóbb az SMT / Hyper-Threading teljes letiltása, amit a biztonságtudatos emberek gyakran megtesznek.
Az új Linux 4.20-kernek legnagyobb lassulása a Spectre 2-es változat enyhítésének tudható be hogy a Linux alapítója, Linus Torvalds most korlátozni akar.
Ekkor merül fel a kérdés, hogy szükséges-e alapértelmezés szerint engedélyezni a STIBP-t, amikor az SMT / Hyper-Threading már le van tiltva azok számára, akik valóban törődnek a biztonsággal.
Míg, A normál felhasználók számára az 50% -os teljesítményveszteség jelentõs tényezõ, amely elszámolhat néhány problémát és hogy kétséges, hogy ezeket az elméleti sebezhetőségeket érdemes-e gátolni.
Torvalds megköveteli, hogy a STIBP alapértelmezés szerint már nincs engedélyezve
Eközben Linus Torvalds úgy véli, hogy a Spectre v2 alapú gyakorlati támadások nem valószínű, hogy normális felhasználói rendszereken fognak megjelenni.
Linus Torvalds szerint a böngészők jelentik a támadások fő célpontját, amelyek már fokozott védelmet nyújtottak szintjükön (a fenyegetés olyan elszigetelt JIT folyamatokra vonatkozik, amelyekre szelektív védelmi módszer fejleszthető).
Se javasolja alapértelmezés szerint csak a Spectre védelmi módszerek használatát, amelyek nem vezetnek a teljesítmény nagy csökkenéséhez, ehelyett szelektíven vagy opcióként további módszereket alkalmaznak.
Tehát miért lassul az a STIBP alapértelmezés szerint, amikor azok az emberek, akiknek * valóban gondjuk van, már letiltják az SMT-t?
Azt hiszem, ugyanazt a logikát kell használnunk, mint az L1TF esetében - alapértelmezés szerint nem tudjuk eltávolítani a teljesítményt. Tegyen egyszer értesítést erről, és hagyja, hogy az őrültek azt mondják: "Inkább 50% -os sikerarányt érek el, mintsem elméleti probléma miatt aggódni." Linus torvalds
Az STIBP alapértelmezett használatát vissza kell állítani
Továbbá, Az Intel Arjan van de Ven szerint az Intel és az AMD alapértelmezés szerint nem javasolja a STIBP használatát, mint hogy ez a funkcionalitás összehasonlítható egy nagyon nehéz kalapáccsal, mivel nem használják a mindennapi munkában, de bizonyos körülmények között szükséges.
Azt állítja, hogy a mikrokód frissítésben javasolt STIBP mechanizmus lehetővé teszi a processzor gyorsítótárainak leállításának ellenőrzését egy speciális bit beillesztésével a CR0 regiszterbe, amelyet nem mindenhol szabad elvégezni, hanem csak különösen kritikus helyzetekben.
Az Intel Tim Chen azt javasolta, hogy a sandbox-támadások szelektív blokkolása csak akkor tartalmazza a STIBP-t, ha azt kifejezetten a prctl-en keresztül kérik, vagy olyan folyamatok esetében, amelyek tiltják az alapmemória-kiírások (PR_SET_DUMPABLE) létrehozását, mint például az sshd.
Ami a teljesítménycsökkenést illeti, amikor STIBP javításokat használunk a Linux Kernel 4.20 rendszeren, az eredmény nagyban függ a terhelés típusától.
Például az elvégzett tesztek azt mutatták, hogy a SpecInt Rate 2006 csomag 21% -os teljesítménycsökkenést mutat, míg a Phoronix tesztek 3% és 20% közötti teljesítményromlást mutatnak.
Ingo Molnar, a Linux Kernel egyik ismert fejlesztője és a CFS Task Scheduler szerzője a helyzetet kommentálva javasolta a teljesítményteszt információs változáslistájának hozzáadását, amikor a problémákra megoldásokat adnak.