A Linux kernel lassan beépíti az Intel processzorokban felfedezett sebezhetőségekre adott javításokat, amelyek a 4.20-as verzióban már élnek is. A probléma ezekkel az, hogy némelyik javítás iszonyatosan teljesítménygyilkos. Ilyen a Spectre v2-re adott tapasz, amire az Intel háromféle megoldást javasol: IBRS (Indirect Branch Restricted Speculation), IBPB (Indirect Branch Predictor Barrier), illetve STIBP (Single Thread Indirect Branch Predictors). Az IBRS és az IBPB korlátozza a spekulatív végrehajtást a közvetett programmemória-címzéssel dolgozó elágazások esetében, de ezekkel elég sok teljesítményt lehet veszteni. Emiatt az operációs rendszerek fejlesztői szinte kivétel nélkül az STIBP-t implementálták, ami gyakorlatilag kikapcsolja az elágazásbecslést az adott, Hyper-Threadinget támogató mag virtuális szálára vonatkozóan.
Hirdetés
A Linux 4.20-as kernelével a teljesítménycsökkenés változó, a Phoronix tesztje alapján van úgy, hogy csak 5-8%-ról beszélünk, de esetenként akár 30%-nál nagyobb tempóveszteséget is be kell nyelni, de nem túl kedvező esetben ez lehet akár 50% is.
Természetesen az operációs rendszerek fejlesztőinek a biztonság az első, nem kérdés, hogy számukra ezeket a javításokat aktív formában kell szállítani a felhasználók felé, még akkor is, ha az nagyon fog fájni a Hyper-Threadinget támogató Intel processzoroknak. A probléma az, hogy bizonyos tesztek esetében egyszerűen jobban járna a felhasználó, ha szimplán le lenne tiltva az említett eljárás, ugyanis a virtuális szál kikapcsolásához viszonyítva nagyobb tempóveszteség lehet a virtuális szálon letiltani az elágazásbecslést. Nem beszélve arról, hogy bizonyos programoknak sokkal fontosabb az elágazásbecslést biztosító hardver állandó működése, mint az a pár extra szál, amit a Hyper-Threading ad.
Azt semmiképpen nem állítjuk, hogy az operációs rendszerek fejlesztői rossz megoldást választottak az STIBP implementálásával. A biztonság ezzel megvan, de látva a lassulást, talán figyelembe kellene venni pár alternatívát is. Például egy külön opciót elhelyezni az alkalmazások futtatásához, ami arra lehetne jó, hogy a Hyper-Threadinggel rendelkező processzort használó réteg dönthessen a virtuális szálak direkt kikapcsolásáról, ha az adott program egyszerűen gyorsabban fut ilyen környezetben az operációs rendszerekbe épített új javítások mellett. Ez ugyan az affinitás beállításával ma is elérhető, de nem minden felhasználó tudja, hogy milyen módon lehet ezzel alkalmazásspecifikusan kiütni a Hyper-Threadinget.
Megfontolandó opció lehet még az STIBP implementáció egyszerűen megoldható kikapcsolása. Ez kényes téma, mivel így az operációs rendszer gyakorlatilag nem fedi el a hardverben található sérülékenységet, de egy átlagfelhasználó gépét valószínűleg jóval egyszerűbb módon is meg lehet támadni, tehát egy olyan sebezhetőség foltozásért kell lemondni akár 50%-nyi teljesítményről, ami nehezen kihasználható, illetve talán nem is ez az elsődleges kapu, amit egy támadó keresni fog. A szerverpiacon érthető, hogy ez az egész fontos, de más területeken érdemes lenne módot adni a javítások letiltásra. Ettől ezt még nyugodtan lehet ellenjavallni, de a döntés ott lenne a végfelhasználó kezében.
