A Hyper-Threading sebezhetőség felülvizsgálata

Címkék

Ismét előkerült az LKML-en a Hyper-Threading sebezhetőség kérdés. Mint az ismert, a FreeBSD-s Colin Percival azzal állt elő 2005 közepén, hogy az Intel processzorokban alkalmazott HT megoldásnak biztonsági kockázata van. Akkor a bejelentés hatására több operációs rendszer "gyártó" - többek közt a FreeBSD is, amelynek biztonsági tisztje Colin - letiltotta alapértelmezetten a HT-t a rendszereiben.
A biztonsággal foglalkozók megosztottak voltak a HT sebezhetőség kérdésében, és egy csomóan arra jutottak, hogy a sebezhetőség leginkább elméleti, azt a valós életben kihasználni szinte lehetetlen, vagy legalábbis nagyon nehéz.

Voltak, akik azt mondták, hogy a problémát nem kernel szinten kell kezelni, hanem azokat az userland programokat kell javítani - például az OpenSSL-t, amit azóta ki is javítottak - amelyeknél előfordulhat, hogy bizonyos esetekben érzékeny információt lehetett elcsenni.

Ben Collins egy olyan patch-et szeretett volna elfogadtatni, amely egy konfigurációs opción keresztül letilthatóvá tenné a Linux kernelben alapértelmezetten a HT-t. Alan Cox, Arjan van de Ven és Linus egyetértettek abban, hogy a HT-ből származó biztonsági kockázat olyan kicsi, hogy nem érdemes vele foglalkozni (pretty damn theoretical). Alan szerint lenne azonban értelme a HT letilthatóságának, de annak inkább az lenne az oka, hogy bizonyos terhelési esetekben gyorsabb a rendszer, ha a HT ki van kapcsolva.

Bővebben itt.

Hozzászólások

Nem mondod, hogy a srácok még mindig itt tartanak... :)

"bizonyos terhelési esetekben gyorsabb a rendszer, ha a HT ki van kapcsolva"

Hmm.. nem tudja valaki mik ezek az esetek? Nem vagyok egy HyperThread expert, de érdekelne...

Ense, de anno ezt a cikket talaltam az azota mar megszunt zoxygen blogon(tudja valaki hogy ez azota ujraindult-e mas helyen??). Slashdot bejegyzes.

A cikk szerint az MS SQL szerver fejlesztoi tesztelesekor azt tapasztalatak, hogy ugyanazon a gepen a szerver kikapcsolt HT -vel jobb teljesitmenyt nyujt, mint bekapcsoltal.