Akár 70%-kal is visszavetheti a Linux kernel teljesítményét a Retbleed javítás

Való igaz, de még ha duplán is dolgozik, az a 70% akkor is nagyon durva. A Ratbleed elleni kód egy natív rendszeren lassít 3-5%-ot, jó, legyen 10, duplázzuk meg, mert a VM-ben is levesz max. ugyanennyit, az akkor is max. 20%, nem 70. Itt inkább valami regresszió van simán, ami kapcsolatban lehet magával a Ratbleed-folttal, de nem egyenes következmény.

Hát volt ugye NetSpectre variáns, ami remote, de szerencsére annyira lassú volt, hogy gyakorlatban nem tűnik hatékonynak.

Szerveren a fő para a cloud szolgáltatóknál van, ahol a támadó - random másik előfizetőként - igenis tud kódot injektálni a "saját" VM-jébe. Ha a hypervisor védelmét ezzel ki tudja játszani, akkor szar van a palacsintában. Kérdés, hogy az IDS rendszerek elég jók-e ahhoz, hogy legalább jelezzék a cloud szolgáltatónak, ha valamelyik ügyfél ilyenekkel próbálkozik. Ami cikkeket (jópár éve) olvastam erről, mind arra jutottak, hogy durva teljesítményvesztés bevállalása nélkül még megbízhatóan detektálni sem lehet az ilyen próbálkozásokat. A triviális CPU performance counter alapú detektálás vagy elég könnyen kijátszható volt vagy hajlamos volt fals pozitívakat adni bizonyos fajta valós workloadokra is. Nem tudom fejlődött-e a technika ebből a szempontból.

Vagy csak el kell olvasni mi is van mögötte ugye.

OFF:  Hajbinak mindig igaza van kiveve ha a ™-et hasznalja  :)

Amondó vagyok, hogy félig van igazsága ebben-abban. Bár ez csak mázli szerintem. Körülményektől függ, ki mit csinál, milyen hardveren. Virtuális gépben simán értelmetlen, de pl. gyenge hardveren én is megléptem, hogy letiltottam ezeket a linuxos foltokat (mitigations=off kernelparaméter), mint a Meltdown, meg a többi, pl. ilyen 10 éven 2 mag 4 szálas, régi i5-i7-es Thinkpadeken például sokat számít, C2D-kon még többet, eleve nem acélos gépek, még ha ez a sok folt is levesz, akkor nagyon durván is megérezhető, felhasználástól függően. Nem csak Linuxon, pl. OpenBSD-n is simán engedélyeztem ilyenkor a default tiltott Hyper-Threadinget, mert 2 magos proci nagyon rá van szorulva.

Amúgy FOSS unixlike rendszereken túl is vannak lihegve ezek a sérülékenységek. Hiszen aki ezeket használja, az többségében vagy szinte kizárólag tárolóból vagy ellenőrizhető forrásból telepít, főleg FOSS kódokat, amik a nyíltság miatt eleve nem tartalmazhatnak csúnyaságot, bináris formában meg alá vannak írva, így belebarmolni nem lehet senkinek. Windowson már sokkal kritikusabb, ahol mindenféle weboldalról guberált, szutyok zárt kód lefut. Egyedül a böngésző lehet közös támadási felület, de egyrészt a böngészőket külön is foltozni szokták az ilyen procisérülékenységek ellen, meg ugye ezek alapból sandboxolt megoldások. Legtöbbször már a fordítók is figyelembe veszik ezeket a sérülékenységeket, lásd ratpoline alkalmazása. Így ha a kernelben minden vonatkozó ki van kapcsolva, akkor is marad többszörös védelmi vonal.

Modern hardveren (utóbbi 5-6 generáció, azok, kb. amiket a Win11 is támogat) viszont nem tiltanám le ezeket a patcheket. Ezeken nem hogy nem gyorsít, de több mérés szerint még enyhe lassulást is okoz, mert a foltokba azóta integráltak optimalizációkat is, amikkel nyerhető sebesség a teljesen patch-mentes állapothoz képest. Így pl. Ryzen 2600, 4700U, 6800H, stb. gépeken alapértelmezésben hagyok minden ilyen foltot.