Bár az Intel gőzerővel dolgozik a most még instabil mikrókódjának új, remélhetőleg stabil verzióján, Linus Torvalds azért elmondta a véleményét a vállalat koncepciójáról, amivel a Spectre sebezhetőség branch target injection támadási variánsa ellen próbálnak védekezni. A Linux atyja természetesen most sem hazudtolta meg önmagát, így a levele tele van nyomdafestéket nem tűrő szavakkal. Ezeket a részeket nem különösebben emelnénk ki, a lényeg annyi, hogy Torvalds szerint az Intel nem veszi elég komolyan a problémát, és a javításuk "komplett szemét".
A valóságban egy kicsit árnyaltabb a helyzet. Az Intel a friss mikrokódjában bevezet egy IBRS, azaz Indirect Branch Restricted Speculation nevű javítást, amiben részben a STIBP (Single Thread Indirect Branch Predictors) és az IBPB (Indirect Branch Predictor Barrier) funkciók akadályozzák meg azt, hogy a támadó valamilyen Spectre sebezhetőséget kihasználó implementációval olyan adatok kiolvasására kényszerítse a hardver spekulatív végrehajtását, amelyhez amúgy nem lenne joga egy programnak. Ez eddig tiszta sor, hiszen erről kell szólnia a javításnak, ami kiegészíti például a Google retpoline frissítését.
Linus Torvalds, a Linux atyja
Linus Torvalds azt kifogásolja, ahogy az Intel ezt a problémát kezeli. Amikor van a hardverben valamilyen hiba, illetve jelen esetben egy problémás működést lehetővé tevő feldolgozási mód, akkor azt szoftveresen úgy szokás kezelni, hogy a programban definiálják magát a problémát, az érintett hardvereket, és erre nyilván az adott gyártóval közreműködve felépíthető egy különálló kód, majd relatíve egyszerűen karban is tartható. Ez azért szükséges, mert az optimális működés érdekében sokszor igazodni kell a javítást biztosító mikrokódhoz. A kezelés tehát nagyon egyszerű, ha a probléma egyszer a hardveres oldalon foltozásra kerül, akkor onnantól kezdve az adott elágazásra a processzor azt fogja felelni, hogy már nem érintett, így futhat az alapértelmezett kód is. A meglévő hardverek persze hibásak maradnak, de ezeknek ugye ott az alternatív kódút, amelyet aktivál is a rendszer, amint az adott lekérdezésre azt mondja a konfiguráció, hogy telepítve van a szükséges mikrokód. Végül, ha nincs válasz, akkor vagy túl régi a hardver, vagy a felhasználó még nem végezte el a firmware frissítését, így nyitva marad a sebezhetőség.
Végeredményben tehát a szoftver fejlesztésénél kategorizálásra kerülnek a hibás hardverek, amelyekre lesz egy speciális, direkt a javításra optimalizált kódrész, majd ha jön javított hardver, akkor annak erre amúgy sem lesz szüksége. Persze szó sincs ideális helyzetről, elvégre egy adott gyártón belül másképp kell kezelni az elméletben kompatibilis architektúrákat, összességében azonban még mindig ez a módszer a legegyszerűbb opció. Ez pedig tapasztalat, ugyanis kisebb hibák számos alkalommal kerültek már így javításra, tehát hasonló kezelést igénylő dolgokkal már számtalanszor szembenézett az ipar.
Az Intel – a fentiekkel szemben – ezúttal másképp közelíti meg a problémát, és alapértelmezetten minden lapka támadható marad. A biztosított javítás ezáltal a kelleténél sokkal bonyolultabb, illetve az operációs rendszernek csak azt jelzi, hogy elérhető egy foltozott mód, de ahhoz, hogy az működjön a kernelnek külön kérnie kell az aktiválását, akár a felhasználó külön beleegyezésével. Ez többek között azért probléma, mert például, ha egy régi operációs rendszer nem kerül frissítésre, akkor az nem tudja kérni az IBRS aktiválását, azt sem tudja, hogy létezik ilyen flag.
Linus Torvalds azonban valószínűleg nem ezen borult ki, hanem azon, hogy innentől kezdve úgy kell írni az operációs rendszereket, hogy a jövőben minden létező processzornál külön kóddal kell kezelni a Spectre sebezhetőség kérdését, mert a lekérdezést sosem lehet kivezetni. Mondani sem kell, ez értelmetlen pluszmunka a fejlesztőknek, hiszen elég lenne, elviselni a mostani hibás hardvereket, majd egy évtized múlva, amikor már nem elvárás a ma még használt, de akkorra bőven elavuló processzorok támogatása, ki lehetne vezetni az alternatív kódutat. Az Intel javítása azonban ezt lehetetlenné teszi, minden később érkező hardver számára ott kell lennie a komplex ellenőrzési struktúrának. Mivel ez ellenkezik az alapvető logikával Linus Torvalds tetszését nem nyerte el. Arról nem is beszélve, hogy ez a módszer lehetővé teszi az Intel számára, hogy ne is foltozzák be hardveresen magát a sebezhetőséget, hanem pusztán szoftver oldali, rendkívül komplex kódokat igénylő hackeket alkalmazzanak, amelyek alapértelmezetten nem is aktívak, de mondhatják a biztonságukat féltő panaszkodóknak, hogy kapcsolják be, ha akarják.
Könnyen lehet, hogy a javítás jellegét nem pont a rendszerprogramozók dolgozták ki, hanem nagyon számított, hogy mit mondanak a vállalat jogászai. Ugyanis az Intelnek le kell védenie magát a várható perek ellen is. Ergo még egy szoftver oldali kódban sem vallhatják be, hogy az elmúlt évtizedekben tervezett hardvereik bizonyos szempontból hibásak, az ugyanis komoly fegyvert adna a pereskedők kezébe. Hiába lenne tehát kézenfekvő az ipar és a felhasználók számára egy jóval egyszerűbb, könnyebben karbantartható és tesztelhető, így potenciálisan sokkal kevésbé instabil javítás, ha egy esetleges perben komoly anyagi kárt okozhatna az Intelnek. Emiatt bármennyire is logikátlan, bármennyire is bünteti a felhasználókat, illetve bármennyire zavarja Linus Torvalds egyszerűségre törekvő fejlesztői felfogását, mindenképpen a komplex módszer tűnik védhetőnek, mert nem mondja ki közvetlenül a hardverekről, hogy hibásak.
Jogi értelemben a frissített mikrokód nem is javítást kínál, hanem egy bekapcsolható szolgáltatást. Ez bizonyos esetekben csökkenti majd a teljesítményt, de védetté teszi a konfigurációt a Spectre sebezhetőség branch target injection támadási variánsa ellen. Mindenki maga döntheti el, hogy akarja-e ezt vagy sem. Ezzel az Intel továbbra is reklámozhatja a processzorok teljesítményét a frissítés nélkül, a felhasználók pedig dönthetnek az IBRS aktiválásáról, mérlegelve az előnyöket és a hátrányokat. A probléma ilyen módon történő kezelésébe pedig nagyon nehéz belekötni, elvégre senki sem mondhatja, hogy nincs javítás, de azt sem lehet mondani, hogy nem lesz meg a reklámozott teljesítmény egy bizonyos működési módban. Csupán a kettő együtt nem érhető el, de ezt sosem fogják megemlíteni.
