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
- A hozzászóláshoz be kell jelentkezni
Hozzászólások
Ez már a Microsoft novemberi security patch számánál is magasabb.
- A hozzászóláshoz be kell jelentkezni
Par napja frissult a Debianban az intel-microcode csomag, mondom is, hogy trey mar fogalmazza a cikket. Aztan megse, XMI gyorsabb volt.
- A hozzászóláshoz be kell jelentkezni
És milyen jó kis cikket írt, köszönet érte!
A magyar ember jelképe a hátrafelé nyilazás. Vakon rohanunk a semmibe, miközben a múltunkat támadjuk.
- A hozzászóláshoz be kell jelentkezni
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!
- A hozzászóláshoz be kell jelentkezni
Én úgy fogalmaznék, hogy:
sosem lesz binztonságban senki, mert félévente kiderül, hogy "Intel: broken by design" - lehetne ez az új szlogen :D
- A hozzászóláshoz be kell jelentkezni
jó jó, de jön a patch? tegnap települt valami, biztonság kedvéért rányomtam az OK-ra, akkor most jól megfertőzött az ubuntu?
viccet félretéve, várható teljesítmény csökkenés?
Ha nem válaszolnék kommentben, hát küldj privátot!
- A hozzászóláshoz be kell jelentkezni
"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.
- A hozzászóláshoz be kell jelentkezni
Höhö, AMD-s vagyok! Nem érdekel :)
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
Az AMD Epyc és Ryzen-es híreket, meg lehetőségeket érdemes lenne megvizsgálnod. :)
- A hozzászóláshoz be kell jelentkezni
Higyjük azt, hogy azok kevésbé hibásak.
- A hozzászóláshoz be kell jelentkezni
Nem kell hinni, az AMD processzoroknak éppen úgy van errata doksijuk, mint az Intel processzoroknak. Csak meg kell nézni :)
trey @ gépház
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
Én nem állítottam semmi mást, mint, hogy nem kell hinni, mert az AMD processzorokhoz is van errata dokumentáció. Fogalmam sincs, mi van benne, évek óta nem érdekel a processzor biznisz.
trey @ gépház
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
É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
- A hozzászóláshoz be kell jelentkezni
Azok az idők elmúltak már, mikor az összes amd alá készült chipset úgy volt hulladék ahogy volt?
Hányszor indult újra/állt meg az AMD-s géped 2019-ben nem tervezett okból?
- A hozzászóláshoz be kell jelentkezni
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.
"Az udvariasság olyan, mint a nulla a számtanban. Egymagában mit sem jelent, de sokat változtat azon, amihez hozzátesszük." - Freya Stark 1893 - 1993
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
É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.
- A hozzászóláshoz be kell jelentkezni
" 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.
- A hozzászóláshoz be kell jelentkezni
Sajat kezbe vette a chipset ugyet az AMD es mar a korabbi generacioknal is teljesen voltak. Miota nem neztel ra az amd cuccaira?
- A hozzászóláshoz be kell jelentkezni
Újabban nem annyira AMD. De a lényeg végülis az, hogy ütőképes legyen a platform.
The 300 and 400 series Chipsets are designed in collaboration with ASMedia. The X570 is designed by AMD with IP licensed from ASMedia and other companies.
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
throw new Exception("wtf");
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
Azok az idők a Ryzen-korszak óta megszűntek. Az első generációs, korai Ryzen lapok között még volt pár problémás, de BIOS frissítéssel azokat is orvosolták már.
“A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)
- A hozzászóláshoz be kell jelentkezni
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
- A hozzászóláshoz be kell jelentkezni
Most már szerencsére van megfelelő alternatíva.
- A hozzászóláshoz be kell jelentkezni
Linus tech-tip liked the new AMD:
https://www.youtube.com/watch?v=stM2CPF9YAY
Most people does not like tr3 prices.
Amit nem lehet megirni assemblyben, azt nem lehet megirni.
- A hozzászóláshoz be kell jelentkezni
Én is most vettem Ryzen 2600-asat. Egyelőre kafa.
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
>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
- A hozzászóláshoz be kell jelentkezni
Én jóval rövidebben tegnap bedobtam a témát: https://hup.hu/node/166596
Végén magyar cikkel a prohardvertől. De oldalsávban a HWSW-től is volt tegnap cikk: https://www.hwsw.hu/hirek/61098/intel-mds-zombieload-spectre-exploit-cpu-processzor-biztonsag.html
@ robyboy "nincs alternatíva." - ezt hogy kell érteni? Mert hogy van.
- A hozzászóláshoz be kell jelentkezni
"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
- A hozzászóláshoz be kell jelentkezni
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
- A hozzászóláshoz be kell jelentkezni
Kapcsolódó: a Spectre and Meltdown checker is tud már ilyen zombis meg TAA-s izét.
- A hozzászóláshoz be kell jelentkezni