Új Intel CPU-hibák: Zombieload TAA, iITLB Multihit NX, JCC Errata

Mai napon az Intel - havi rendszerességű biztonsági állapotjelentés keretében - nyilvánosságra hozott összesen 77 biztonsági figyelmeztetést. Ezek jelentős része driver, illetve firmware frissítés, viszont külön kiemelendő két, CPU-kat érintő sebezhetőség, valamint egy harmadik nem biztonsági, hanem stabilitási-jellegű processzorhiba.

A Zombieload TAA (TSX Asynchronous Abort) CVE-2019-11135, (Intel SA-00270), a korábban nyilvánosságra hozott Zombieload MDS (Microarchitectural Data Sampling) két új variánsát takarja.

Az iITLB Multihit CVE-2018-12207 (Intel SA-00210) denial of service támadásra ad lehetőséget memória-laptáblában szándékosan érvénytelen lapméretű bejegyzések létrehozásával. Úgy tűnik itt is egy korábbi hiba újabb variánsáról van szó.

A Jump Conditional Code (JCC) Errata - jelen ismereteink szerint - nem hordoz biztonsági kockázatot, ám ahhoz hasonló mitigációs lépéseket igényel. A hiba feltételes ugrás utasítások 32byte-os kerek címhatárokra kerülése esetén nemdeterminisztikus viselkedésben nyilvánul meg.

Mindhárom probléma csak az Intel processzorait érinti.

A legsúlyosabb, nem-privilegizált olvasásra lehetőséget adó Zombieload TAA olyan processzorokat érint, amik implementálják a TSX (transactional synchronization extension) utasításkészletet. Ez praktikusan jelenti a Broadwell késői steppingjei és a Skylake-től kezdve minden új Intel Core és Xeon processzorát, beleértve a legújabb Cascade Lake processzorokat is.

A Zombieload sebezhetőségekre Proof of Concept kód (PoC) rendelkezésre áll, a tegnapi nap folyamán a PoC kiegészült a két új variánssal. A sebezhetőséget a Cyberus Technology kutatói jelentették még a Zombiload MDS variánsokkal egyidőben, az utóbbi két variánsra meghosszabbított embargó volt érvényben. A kutatók eredeti javaslata a hyperthreading tiltása (nem nyújt tökéletes védelmet, de megnehezíti a támadást), valamint szenzitív adatot kezelő és nem megbízható forrásból származó kódok különböző processzormagon futtatása.

Az Intel a javításra új mikrokódot adott ki, a védelemhez kernel illetve hypervisor támogatás is szűkséges, ezek várhatóan hamarosan érkeznek. (Advisory-t eddig a Xen adott ki, jelenleg még nincs javításuk.) A processzor teljesítményére hatása jelenleg nem ismert.

Az iITLB Multihit-et kihasználó támadó machine check exceptiont vagy CPU lockup-ot tud előidézni, a problémát az Instruction-address Translation Lookaside Buffer-ben különböző méretű lapok (normál illetve hugepage) kezelésének hibája okozza. Elsősorban hypervisorokat érint, a támadónak virtuális gépen belülről van lehetősége laptáblát módosítania. Védekezés a hugepage támogatás letiltása vagy minden hugepage NX (non executable) jelölése, ez garantálja, hogy az iTLB-ben csak 4kB-os lapok legyenek.

Bár nem biztonsági jellegű, a jelenlegi listából a JCC Errata fogja várhatóan legtöbb komplikációt és - sajnálatos módon - teljesítményproblémát okozni. A hiba Skylake és újabb processzorgenerációt érinti. Röviden: a feltételes ugrás (JCC) utasítás nemdeterminisztikus eredményre vezet, amennyiben 32 byte-os kerek egész címen átlóg vagy arra végződik, valamint további - nem részletezett - mikroarchitekturális körülmények fennállnak. A problémát a már dekódolt mikroutasításokat tároló cache (Decoded ICache) megvalósítása okozza, a hiba akkor történik, ha a JCC utasítás cache-line határon átlóg.

Az Intel külön dokumentumot adott ki a hiba leírására és mitigációs lehetőségek tárgyalására. A funkcionális javítás alapvetően mikrokód frissítéssel történik, ám ez a problémás címen elhelyezkedő JCC utasítások esetén letiltja a Decoded iCache használatát és a lassú normál pipeline-on hajtja végre őket. Ez természetesen teljesítménycsökkenéssel jár, az Intel szerint átlagosan 0-4%-ra kell számítani, néhány kivételes esetben (*) lehet ennél több. A Phoronix legfrissebb tesztje, ezt lényegében megerősíti. Fontos megjegyezni, hogy ez a teljesítménycsökkenés máshol jelentkezik, mint a korábbi spekulatív végrehajtás biztonsági hibáit kivédő javításoké. Az utóbbiak jellemzően a rendszerhívások, kontextusváltások futási idejét növelték meg, a mostani javítás viszont elsősorban felhasználói módon belüli normál futásnál okoz gondot. Ez elvileg kiküszöbölhető, ha a fordítóprogram elkerüli a JCC utasítások problémás címre helyezését, erre az Intel már készített patcheket. Azonban egyrészt az eredmények jelenleg vegyesek (lásd Phoronix fenti benchmarkja), másrészt ennek a megoldásnak számos hátránya is van:

  • újra kell fordítani mindent a patchelt fordítóval
  • bináris kiadások esetén értelemszerűen ezt csak a gyártó teheti meg
  • JIT fordítást végző futtatókörnyezetek (Java, CLR, különféle javascript engine-ek, böngészők) esetén nem elég a runtime újrafordítása, a JIT fordítót is külön fel kell készíteni. (*) Ezt a fenti benchmarkok sajnos megerősítik: a böngészők esetén mérhető a legnagyobb, 10%-körüli teljesítményvesztés.
  • a hibában nem érintett processzorok esetén a JCC utasítások áthelyezése várhatóan rontani fog a teljesítményen (jelenleg még nincs ilyen eredmény), sok esetben viszont nem megoldható külön Skylake-x86-64 és egyéb-x86-64 binárisok szállítása

Hozzászólások

Ez már a Microsoft novemberi security patch számánál is magasabb.

Par napja frissult a Debianban az intel-microcode csomag, mondom is, hogy trey mar fogalmazza a cikket. Aztan megse, XMI gyorsabb volt.

valaki írna egy tl;dr verziót laikusoknak? pl. hogy ez megint ilyen "hopp felére esik a processzorod teljesítménye", vagy "hopp sose lesz biztonságban senki mert nem lehet javítani", ...?

Ha nem válaszolnék kommentben, hát küldj privátot!

"böngészők esetén mérhető a legnagyobb, 10%-körüli teljesítményvesztés"

Hajbazert varjak az uszodapenztarnal.

Ures ez a topik "tervezett elavulas" meg "engem ugyan at nem vernek, kikapcsolom a frissiteseket" nelkul.

Höhö, AMD-s vagyok! Nem érdekel :)

Az elmélet az, amikor mindent ismerünk, de semmi nem működik. A gyakorlat az, amikor minden működik, de senki nem tudja, miért.

Azért pár évtizedig elég jól tudták titkolni a szakma elött is, hogy folyamatosan hibás hardvereket gyártanak.

Változnak az idök. Most már tudjuk, hogy hibás, amit veszünk jó drágán, mégis kifizetjük érte a nagy lóvét, mert nincs alternatíva.

robyboy

Nem hisszuk, hogy hibatlanok, de az eddigiek szerint kevesebb es legalabbis ritkabban elofordulo a buglista, illetve nincs teljesitmeny problema. Epp ezert a nincs alternativa eleg eros kijelentes.

Mivel 1,5-2 eve izzad a ryzenek es epycec miatt az intel, nem gondolnam, hogy ne derulne ki barmilyen hajszalni bug.

Ez ilyen tipusu hibak ritkabbak.

Nehany AMD hiba:
https://developer.amd.com/wp-content/resources/56323-PUB_0.74.pdf
https://www.amd.com/system/files/TechDocs/55449_Fam_17h_M_00h-0Fh_Rev_G…

Nehany Intel hiba:
https://www.intel.com/content/dam/www/public/us/en/documents/specificat…

Hibak tobbsege nem erint user space kodot,
kernel space -ben meg kikerulik.

Kulon viccess hogy az Intel Specification Update-nek nevezi.

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Én már az AMD Phenom processzorral is elvoltam, bár ugyan nem az volt a leggyorsabb gép, de persze annak idején nem is volt drága. Ár-érték arányban akkor is jó választás volt, de mondjuk akkor akinek csúcsteljesítményre volt szüksége, annak lehet nem volt tényleges alternatíva.

Most viszont az Intel már csak több áramot fogyaszt és jobban is melegszik, és még ehhez jönnek a már lassan havi szinten kikerülő biztonsági hibák. Az Intel processzoroknak leginkább már csak akkor nincs alternatívája, ha fűtésre is használod. Az új AMD Ryzen azonos fogyasztás mellett szinte minden esetben verik az Intel párjukat teljesítményben. Van még pár játék, ahol a csúcskategóriában az Intel processzoroknak van pár FPS előnye, de pl. a 7-Zip tömörítésnél illetve sok videóvágási feladatban tetemes előnyük van Ryzeneknek.

Nagy Péter
www.ddo.hu

Bár nem tőlem kérdezted, de mivel 2017-ben vettem AMD Ryzen-es gépet, talán az én válaszom is meg fog felelni.

 

A válasz pedig az, hogy 0 alkalommal, az áramszüneteket nem számítva. Tökéletesen elégedett vagyok a géppel, gyors, halk, keveset fogyaszt, egyszerűen csak használom és megy.

ASRocK lap AMD B350-es chipset, 0 hiba, probléma. Bootoltam rajta Windows-t, Linux-szokat, GhostBSD-t, Android-ot, hiba nélkül ment mind.

Hozzátenném, Pentium3-ról váltottam AMD-re, azóta egy letöltögetőgépen kívül asztali gépem csak AMD-s volt, VIA chipset-es, AMD chipset-es, Nvidia Nforce-os, soha nem volt stabilitásbeli problémám velük. Nagycsaládon belül ma is 7 AMD-s gép fut, AMD Athlon-tól a Bulldozer-en át Ryzenig, 0 stabilitási problémával. Gépet összerakni tudni kell, a stabilitási problémák az esetek 70%-ánál a nem megfelelően kiválasztott részegységekre vezethetőek vissza.

A Linux nem ingyenes. Meg kell fizetni a tanulópénzt.
Az emberek 66 százaléka nem tud számolni! Gondoljatok bele, ez majdnem a fele!!
Mindenki jó valamire. Ha másra nem, hát elrettentő példának.

Ryzenesként beszállok én is.

Egyszer sem, eddig csak olyan bajom volt, hogy alvó módból nem mindig jön vissza. De ilyen bajaim voltak anno Intel Haswell alatt is, Linux alatt a desktop alvó mód nem az igazi valahogy (Thinkpaden sosem volt gondom még szerencsére, ott húsba vágóbb lenne).

Nekem egyébként Ryzen APU-m van (2400G) és azt kell mondjam, sikerült végre összelapátolni a Linux drivert is az AMD-nek, teljesen elégedett vagyok vele. Még játszani is lehet vele, már csak a Freesync támogatást hiányolom, de az apróság (meg hogy a Linux kevésbé legyen szar, mint játékplatform úgy általában).

Az egyetlen igazi szívfájdalmam, hogy kedvet kaptam szórakozni deep learninggel, de ahogy nézem az a terület gyakorlatilag nVidia only, a könyvtárak vagy CUDA-t használnak, vagy olyanok, amilyenek. Hétköznapi felhasználásra viszont szinte hibátlan az AMD már.

Én utoljára Athlon XP (Barton) korszakban használtam AMD -t otthon (később cégben Phenom II X4-et, de annak a hardvereire már nem emlékszem). Szóval a Barcit támogató nForce chipset tök szuperül működött, betonstabil volt Windows és Linux alatt is, működött mindene.

arch,ubuntu,windows,android
zbook/elitebook/rpi3/nokiax6_DRG_sprout

" Azok az idők elmúltak már, mikor az összes amd alá készült chipset úgy volt hulladék ahogy volt? " - El.

5, azaz öt darab AMD desktop van a háztartásban és 1, azaz egy darab Intel-es. (Most a pontos konfigokat nem fejteném ki). Lefedi az lemúlt 3-4 generációt.

Az Inteles néha nem bootol be. De elnézem neki, ajándék volt. AMD meg azért lett, mert nem szeretem otthon a drámát, meg azért árérzékeny is vagyok. Az árkülönbözetből inkább veszek a gyerekeknek még pl. legót.

0
Desktop/server Intel-el sem volt bajom ilyen teren.

Az alaplapi sensor tamogatas a legnagyobb bajom,

ha problema nem oldja meg magat  hamarosan(mas kitatllaja melyik register mit csinal),
akkor en nezem meg.

it8792-isa-0a60 -nak latja rendszer, de nagyon tavol al a valosagtol amit mutat.

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

it8792-isa-0a60
Adapter: ISA adapter
in0:          +1.75 V  (min =  +0.00 V, max =  +2.78 V)
in1:          +0.67 V  (min =  +0.00 V, max =  +2.78 V)
in2:          +0.98 V  (min =  +0.00 V, max =  +2.78 V)
+3.3V:        +1.67 V  (min =  +0.00 V, max =  +2.78 V)
in4:          +1.77 V  (min =  +0.00 V, max =  +2.78 V)
in5:          +1.18 V  (min =  +0.00 V, max =  +2.78 V)
in6:          +2.78 V  (min =  +0.00 V, max =  +2.78 V)  ALARM
3VSB:         +1.66 V  (min =  +0.00 V, max =  +2.78 V)
Vbat:         +1.56 V  
fan1:           0 RPM  (min =    0 RPM)
fan2:           0 RPM  (min =    0 RPM)
fan3:           0 RPM  (min =    0 RPM)
temp1:        +42.0°C  (low  = +127.0°C, high = +127.0°C)  sensor = thermistor
temp2:        -55.0°C  (low  = +127.0°C, high = +127.0°C)  sensor = thermistor
temp3:        +38.0°C  (low  = +127.0°C, high = +127.0°C)  sensor = thermistor
intrusion0:  ALARM

acpitz-acpi-0
Adapter: ACPI interface
temp1:        +16.8°C  (crit = +20.8°C)

k10temp-pci-00c3
Adapter: PCI adapter
Tdie:         +51.0°C  (high = +70.0°C)
Tctl:         +51.0°C

 X570 AORUS PRO

Mas sensort hasznalo lapokkal lehet nincs baj.
Fan rpm -nem latszik.

3.3V nem 3.3 V .
  -55 degC nel melegebb van.

Valszonuleg, csak ki kell talani melyik ertek micsoda valojaban es megfeleloen ertelmezni.
Nem lenek meglepve, ha win driverek ini -fileibol ki lehete olvasni .

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Nekem még most is ilyenem van:

AMD Phenom(tm) II X4 955 Processor

Semmi bajom vele, teszi a dolgát, nem szokott megdögleni. Az alaplap, amiben van, már elmúlt 11 éves. Nem kezdettől fogva van benne ez a CPU, néhány évvel később lett ez. Csak azért írom, mert ha netán ez a CPU kevesebb, mint 11 éve jelent volna meg, a fent írottak nem vezetnek ellentmondásra.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Most már szerencsére van megfelelő alternatíva.

Én is most vettem Ryzen 2600-asat. Egyelőre kafa.

Elgondolkodtam a ryzenen én is (évek óta nem igazán követem az alaplapok, CPU-k fejlődését), de egyelőre várok. Nekem a teljesítmény nem igazán fontos, fusson elfogatható sebességgel az, amit használok (jellemzően böngészés, zenehallgatás, videó, némi programozás, de semmi komoly erőforrásigény - nem játszom erőforrásigényes játékokkal. Fogyasszon minél kevesebbet, és nem akarok külön videokártyát. És itt van gondom: LInux alatt mennyire támogatottak az AMD integrált megoldásai? Amennyire tudom, az nVidia és az AMD esetén is igazából a zárt meghajtók működnek megfelelően, ott meg időről időre kikerülnek a régebbi eszközök a támogatott listáról, én pedig nem szeretnék úgy járni, hogy amiatt kell hardware-t upgrade-elni, mert kikerült a support a driverből.

>Amennyire tudom, az nVidia és az AMD esetén is igazából a zárt meghajtók működnek megfelelően

Erősen elavultak az információid, az AMD ráfeküdt a nyílt vonalra az utóbbi években, kb. utolérték az Intelt. Már csak az nVidia a hunyó Linux fronton, amíg nem kritikus felhasználási mód a PC játék, addig egy sima AMD + Mesa már bőven több, mint elég. Sőt, igazából már játékokra is egyre inkább megfelelő (bár itt a Linux ökoszisztéma úgyis szűk keresztmetszet lesz még sokáig).

Fentebb írtam a tapasztalataimat a Ryzen APU-król: https://hup.hu/comment/2405968#comment-2405968

"Ez praktikusan jelenti a Broadwell késői steppingjei és a Skylake-től kezdve minden új Intel Core és Xeon processzorát, beleértve a legújabb Cascade Lake processzorokat is."

- tehát az ennél régebbi Intel procikat nem érinti?!.

"a hibában nem érintett processzorok esetén a JCC utasítások áthelyezése várhatóan rontani fog a teljesítményen (jelenleg még nincs ilyen eredmény), sok esetben viszont nem megoldható külön Skylake-x86-64 és egyéb-x86-64 binárisok szállítása"

- vagy akkor mégis? Nem vagyok szakember, érinti ez utóbbi az amd-n futó rendszer sebességét?

"Nem akkor van baj amikor nincs baj, hanem amikor van!"
Népi bölcsesség

Majdnem azt írtam, hogy nem. Ami kellemetlen, hogy x86_64 kompatibilitás miatt fordítási időben nem lehet tudni azt, hogy a bináris AMD-n, vagy kehes Intelen lesz-e futtatva, így gondolom, beszúrnak a kódba egy-egy NOP-ot, ha a feltételes ugrás address modulo 32 = 0-ra esne. Viszont ez akkor is a kódban lesz, ha azt AMD-n futtatod, így az a kellemetlen, hogy szerintem lesz emiatt teljesítménycsökkenés.

Azt el tudnám képzelni, hogy a gcc-nek legyen olyan kapcsolója, amellyel meg lehet mondani a konkrét CPU típust, így AMD-re fordításnál ezzel nem bajlódnának, s optimális lenne a kód, de aligha hiszem, hogy mától fogva a bináris kódot szállító disztribútorok minden x86_64-es kódból kétfélét fordítanának. Lényegében kiszúrt velünk az Intel, mert a workaround egy vacakabb kód, s az mindenhol vacakabb.

Menekülési útvonal a forrás alapú disztribúciók lehetnének, mint pl. a Gentoo, mert lehetne specifikusan jó AMD - helyesebben szólva ezzel a hibával nem rendelkező - CPU-ra fordítani.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Használjatok Power mert az jó!

Sic itur ad astra!