Theo de Raadt az Intel Core 2 Duo processzorok biztonsági hibáiról

Intel

Theo de Raadt, az OpenBSD projekt vezetője tegnap este egy, a misc@ listára küldött levelében arról ír, hogy nem javasolja jelenleg a C2D Intel processzorok vásárlását, mert azok komoly bugokkal teliek. Theo szerint ezekben a napokban a különböző fejlesztők azzal vannak elfoglalva, hogy workaround-okat készítsenek a C2D processzorok bugjaihoz.

Theo szerint ezek a processzorok "pokolian" bugosak és ezen bugok közül van olyan, amely nem csak fejlesztési / hibakeresési problémákat okozhat, hanem kétségtelenül kihasználható userland kóddal, kódból. A vezető levele szerint a BIOS gyártók szokás szerint lassan készítik a javításokat és workaround-okat a bugokra. Vannak a bugok közt olyanok, amelyek Theo szerint javíthatatlanok és nem áthidalhatók. A levélben foglaltak szerint az Intel csak a BIOS gyártóknak és a nagy operációs rendszert gyártó csoportoknak ad részeletes magyarázattal ellátott javításokat. A nyílt forrású rendszerek nagy része magára maradt.

"At this time, I cannot recommend purchase of any machines based on the Intel Core 2 until these issues are dealt with (which I suspect will take more than a year)."

( "Jelenleg nem javaslom semmilyen Intel Core 2-re épülő gép vásárlását mindaddig, amíg ezeket a problémákat le nem kezelik (ami gyanítom, hogy több mint egy évet vesz igénybe)." )

A szál itt kezdődik.

(További részletek a bugokkal kapcsolatban a The Inquirer cikkében. A hírek szerint a Microsoft már patch-elt.)

( tamaas | 2007. 06. 28., cs – 16:34 )

Az egy dolog, hogy vannak hibák a prociban, de emellett vannak azért jó tulajdonságai is...

Meg mit ajánl helyette? Új és jó teljesítményű notebookot nem is nagyon lehet más procival venni...

Üdv: Tamaas

"Az egy dolog, hogy vannak hibák a prociban, de emellett vannak azért jó tulajdonságai is..."
Ha azokkal a hibakkal priv. escalationt lehet elkovetni (rovidtavon) javithatatlanul, akkor nehez olyan jo tulajdonsagot mondani, ami ezt kepes ellensulyozni.

--
Fontos feladatot soha ne bizz olyan gepre, amit egyedul is fel tudsz emelni!

Ha komoly hibák vannak, akkor azt a következő stepping-ben ki fogják javítani. A régebbiekhez meg vagy lesz microcode frissítés / BIOS workaround, vagy nem. Az utóbbiban nem igazán hiszek. Ha nem lesz hozzá javítás, akkor valószínűleg vissza fogják hívni a processzorokat és ki fogják cserélni őket.

--
trey @ gépház

A Dell már napokkal ezelőtt frissítette a BIOS-ait. Theo valószínűleg egy kicsit kiszínezte a dolgokat.

A COUPLE OF WEEKS ago, we heard that Dell was dealing with a certain situation considering Intel dual-core MCW and quad-core KC marchitecture, and that the company was releasing urgent BIOS and microcode versions for its line up.

Az érintett CPU-k a The Inquirer szerint:

We learned that the affected CPUs are the Core 2 Duo E4000/E6000, Core 2 Quad Q6600, Core 2 Xtreme QX6800, QX6700 and QX6800.

In the mobile world, people with the Core 2 Duo T5000 and T7000 need to visit Microsoft's site, while the server guys will want to use motherboard BIOSes if they do not rely on Microsoft Windows operating systems.

The affected servers are Xeon 3000, 3200, 5100 and 5300s - or just about every model from the second generation of Core marchitecture.

Oddly enough, Yonah - 32-bit Core Duo processor - isn't among the affected cores.

Bővebben a linkelt cikkben.

--
trey @ gépház

Ennyire azért nem egyszerű a helyzet. A hibák jórészét nem lehet mikrokód frissítéssel megszüntetni, mert nem abban van a bug. A legtöbb utasítást már direkt dekódolják és hajtják végre, csak a legbonyolultabbak vannak mikrokódban, amelyek viszont tipikusan nem futtathatók userlandből (ring3), csak kernel szinten (ring0), pl.: ring váltások, invplg, stb.

Szóval nem véletlenül van egy csomó hibánál az írva, hogy nem lesz rá javítás. Az más kérdés, hogy ezeket mennyire lehet kihasználni. Én azt gondolom, hogy Theo azért egy kicsit túlzott, amikor azt írta, hogy *BIZTOSAN* exploitálhatók userland-ből... ;)

"Ennyire azért nem egyszerű a helyzet. A hibák jórészét nem lehet mikrokód frissítéssel megszüntetni, mert nem abban van a bug."

Mintha három dolgot írtam volna, amiből kiragadtál egyet.

A lehetséges megoldások:

- új microcode / BIOS / OS workaround
- stepping léptetés
- csere

--
trey @ gépház

( bastya_elvtars | 2007. 06. 28., cs – 17:12 )

Észrevettétek, hogy mindig az a bugos, amit az OpenBSD nem vagy szarul támogat? :-D
It doesn't matter if you like my song as long as you can hear me sing

Csak egy ócska Celeron M van a mezítlábas R50e-mben. Most legalább fikázhatom a munkatársam Sony Vaio-ját (1,66Ghz Core2D, 2Gb RAM, 160Gb vinyó, kamera, memória kártya olvasó, bluetooth, 1200 dollár ajándék Lexmark multifunkciós tintasugaras printerrel)! :)

"Jegyezze fel a vádhoz - utasította Metcalf őrnagy a tizedest, aki tudott gyorsírni. - Tiszteletlenül beszélt a feljebbvalójával, amikor nem pofázott közbe."

( sibike | 2007. 06. 28., cs – 17:41 )

Megmondom őszintén ilyen címet vártam: "AMD az Intel Core 2 Duo processzorok biztonsági hibáiról" Ráadásul nem most, hanem legalább fél éve.

Ja? Kétlem. Ez a vásárlóközönség 99.97%-át

- nem érdekli
- nem tudja feldolgozni
- nem jut el hozzá

Így szerintem rajtunk és Theo de Raadt-on kívül ez sok ember nem érdekel. Marketshare-t pedig szerintem igen-igen valószínűtlen, hogy módosítana / módosított volna. Esetleg ha eljutnánk egy visszahívásig. De még akkor sem hiszem.

--
trey @ gépház

Így van. Ezért nincs nekem ilyen processzorom :)) Nem ugrom azonnal a legújabb hardverek után (nem szivatom magam, ha nem muszáj). Ez az egyik szabály. Jól le vagyok maradva. Nekem még Core sincs, nem hogy Core 2.

processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 13
model name : Intel(R) Pentium(R) M processor 1.73GHz

Egyébként örülök, hogy idézel. :))

--
trey @ gépház

( n0gabor | 2007. 06. 28., cs – 18:41 )

Hű akkor most dobjam ki a c2d-met? Majd telen berakok a prescottot helyette, rasegit egy kicsit a padlofutesre legalabb :P

Egyebkent egy atlaguser szamara mit jelentenek ezek a bugok?

::powered by Archlinux

( uid_228 | 2007. 06. 28., cs – 18:41 )

Az összes Apple-user fekete pulóvere fehérre sápadt ijedtében a hír hallatán. :)))

--
Sokan nincsenek tudatában annak, / hogy egyszer mindenki meghal. / Akik ráébrednek erre, / azonnal abbahagyják az ellenségeskedést.

Nem sapka, kávézólánc, emlékeim szerint Seattle környékén alapították. Az angolszászok a főzös műsoraik, borokkal foglalkozó könyveik és újságjaik után fölfedezték maguknak azt is, hogy a világon rajtuk kívül szinte mindenhol fejlett kávézási kultúra alakult ki. :)

Még talán Slashdoton olvastam valahol, hogy az Apple-reklámok által sugárzott kép a felhasználóiról (creative professional, ugye :) ) ilyen, csórikám ül a Starbucksban a Mac laptopjával, csíkszemüveggel, fekete garbópulóverben és munka közben issza a lattéját (szar lehet, ha egy nyelvben nincsen saját szavuk a tejeskávéra :))).

--
Sokan nincsenek tudatában annak, / hogy egyszer mindenki meghal. / Akik ráébrednek erre, / azonnal abbahagyják az ellenségeskedést.

Jartal mar te Starbucksban? Tobb fajta kave van mint amit el tudsz kepzelni, nem csak a barna szinu forroviz. Es ez csak egy ocska atlagos kavezo.

Csak hogy ne legyek teljesen off, ha ezek a hibak valoban leteznek is, ketlem hogy barki is kihasznalna oket. Ehhez mar olyan szintu tudas kell hogy atlag usert szerintem nem erint. Akit igen az meg meg tudja oldani hogy upgradel/cserel/workaroundol.

Azért az egyik hiba, amire Theo az Undeadlyre is kirakott levelében hivatkozik, kicsit valóban meredek. Most fejből nem rémlik pontosan és időm sincs visszakeresni, de a REP bizonyos használata esetén ír az Intel doksija "unpredictable behaviour"-t. Ez ugye egy tök átlagos utasítás, ami ring3-ban is korlátozás nélkül használható. Vajon milyen módon jön elő ez a megjósolhatatlan viselkedés? Azért az nem túl vicces, ha egy akármilyen userland program elránthatja magával a gépet.

(Bár egy régi fórumpostból úgy rémlik, hogy OpenBSD-n erre a MySQL másféle processzoron is képes. :))))

--
Sokan nincsenek tudatában annak, / hogy egyszer mindenki meghal. / Akik ráébrednek erre, / azonnal abbahagyják az ellenségeskedést.

( Ice | 2007. 06. 28., cs – 19:34 )

Theonak lehet, hogy igaza van, sajnos!

Az utolsó mondat sem rossz :)

(While here, I would like to say that AMD is becoming less helpful day
by day towards open source operating systems too, perhaps because
their serious errata lists are growing rapidly too).

- Nagymama ! Miért olyan nagy az arcod ?
- Mert Debiant használok !

Szerintem ez csak érdekessé teszi a helyzetet. :) Már tizen-iksz évesen is imádtam a 8502-es nem dokumentált opkódjait használni. :) Ez kb. ugyanaz, csak itt nem az assembly dump olvasását és megértését nehezíti meg, hanem ha ügyes vagy, akkor hirtelen több jogod lesz, mint volt. :))

--
Sokan nincsenek tudatában annak, / hogy egyszer mindenki meghal. / Akik ráébrednek erre, / azonnal abbahagyják az ellenségeskedést.

Szerintem 6502-re gondolt, de majd ő eldönti. Legalábbis C64-ben az volt, és annak voltak jó kis nemdokumentált utasításai. A hiányzókból kb 90%-ot kis teszttel és egy jó debuggerrel (pl amilyen a +4-ben volt) ki lehetett deríteni, de asszem 2 vagy 3 maradt számomra fölfedezetlen).

Na ja, wikipedia: The C64 used an 8-bit MOS Technology 6510 microprocessor. This was a close derivative of the 6502, with an added 6-bit internal I/O port that in the C64 is used for two purposes: to bank-switch the machine's ROM in and out of the processor's address space, and to operate the datasette tape recorder.

Szóval lényegében mindegy hogy 6502 vagy 6510, bár nem írják itt hogy mi a "close derivative".

Az, a close derivative, hogy a 6502 es a 6510 kozott pontosan az az egy kulonbseg van, amit te is leirtal... :) Egyebkent a csalad tobbi tagjai kozott is kb. ilyen minimalis elteresek vannak. A processzormag kvazi ugyanaz, 1-2 dolog van mashogy kidrotozva, mas a labkiosztas, stb.

-=- Mire a programozó: "Na és szerintetek ki csinálta a káoszt?" -=-

( arpi_esp v | 2007. 06. 28., cs – 23:59 )

Az addig ok, hogy theo szerint kb 1 ev kell a bugok javitasara. De az az errata tablazat (a gif kep) 2006 januari datumu. Tehat mar boven kijavitottak a mai procikban, nemde?

Masreszt vegigolvastam a tablazatot, es egyik sem olyan bug ami miatt nem tudnek nyugodtan aludni, ha lenne core2 szerverem.

A'rpi

( fraque | 2007. 06. 29., p – 02:50 )

Az azért szép, ahogy nem ajánlja a Core 2-t, aztán mondja, hogy ő nem szok ajánlani :) Szerintem annyiban viszont igaza van, hogy az OpenBSD nem nagyon fogja megkapni a szükséges doksikat, hogy processzorhibákat cirkumveniáljon OS-ből.

Mellesleg a C2D ótvarsága nekem a világ legnagyobb PC-gyártójának business kategóriájú notebookjaival lett nyilvánvaló. 10-ből 4 rendszeresen dobál védelmi, meg mittomén hibákat (delehethogyavindózaszar:D), 1-2 bele is hal az életbe úgy 5 percenként, legalábbis egy nagyobb év eleji eresztéssel biztosan voltak ilyen gondok.

Ez nem elfogultság, hanem logika. Ha 10 Intel processzoros gépből 4 állandóan védelmi hibát generálna a Windows-ban illetve "lehalna 5 percenként" akkor az Intel gyárát már rég lerombolták volna, az emberek nem vennének Intel processzort, a részvényesek pedig csődbe jutottak volna. Ilyen eseményekről nem tudok. Te?

--
trey @ gépház

Ebben igazad van, de nem erre a hozzászólásra gondoltam, hanem végigolvasve a topicot.
Nekem egyébként semmi gondom se az AMD-vel se az Intellel. Ha lenne pénzem rá akkor most C2D-t vennék, szóval beletartozok az általad említett 99.97%-ba.

Nincs ebben semmi elfogultság. Én tisztában vagyok azzal, hogy a világ összes processzoroknak megvannak az ilyen, vagy hasonló hibái. Ha valamelyiket mellőzni vagy preferálni fogom, akkor nem hiszem, hogy majd ilyen Theo féle bemondások alapján teszem. Vannak nála hitelesebb források is (nem a geek.com 2006-os .gif-je).

--
trey @ gépház

Nem biztos, persze. De mivel Core 2-t jóformán csak komplett platformként tudsz venni, egyrészt le is szarom, hogy minek a hibája, másrészt meg BIOS verziótól függően több-kevesebb hibát produkált. Amelyik végül szervizbe ment, azon biztos nem csak egy komponens volt rossz.

Nekem ebben csak az volt furcsa, hogy van egy gyártó, aki megbízható, strapabíró notebookokat gyárt és egyszercsak elkezdi ontani a szemetet a teljes palettán, iparitól barkácsig. Biztos véletlenül...

( Chain-Q v | 2007. 06. 29., p – 09:35 )

Hmmmm... Iszonyatos bugosak az Intel procik? Ez egyesek szamara meg mindig kepvisel hirerteket? :)

-=- Mire a programozó: "Na és szerintetek ki csinálta a káoszt?" -=-

Viccesnek vicces, de igazából ha belelapozok mondjuk az Opteron processzorok errata-jába, akkor ilyeneket olvashatok benne:

61 Real Mode RDPMC with Illegal ECX May Cause Unpredictable
Operation

Potential Effect on System
Incorrect instruction decode leading to unpredictable system failure.

Suggested Workaround
When in real mode, restrict use of the RDPMC instruction to the legal counter values (0–3). This
circumstance is not expected to occur in normal operation and has only been detected in a simulation
environment.

Fix Planned
Yes

vagy

62 Task Gates With Breakpoints Enabled May Cause Unexpected
Faults

Potential Effect on System
Unexpected faults leading to unpredictable system failure.

Suggested Workaround
When running software that uses task gates with CALL or JMP instructions, do not enable debug
breakpoints.

Fix Planned
Yes

És így tovább.

Tekintve, hogy amióta van processzorgyártás, azóta vannak revíziók és stepping-ek, kijelenthetjük, hogy hibátlan processzor nincs. Továbbá, hogy Theo de Raadt felfedezte a szarban az ütőeret. Azaz valaki a kezébe adott egy errata-t, amin elcsodálkozott, hogy "jé, ilyen van?" majd megsértődött, hogy "nekünk mér' nem szóltak?" miközben mások már hónapokkal ezelőtt tudtak a javításról :))

--
trey @ gépház

Na egy TLB-s itt is.

122 TLB Flush Filter May Cause Coherency Problem in
Multiprocessor Systems

Description
Under highly specific internal timing conditions in a multiprocessor configuration, coherency
problems may arise between the page tables in memory and the translations stored in the on-chip
TLBs. This can result in the possible use of stale translations even after software has performed a
TLB flush.

Potential Effect on System
Unpredictable system failure. This scenario has only been observed in a highly randomized synthetic
stress test.

Suggested Workaround
In multiprocessor or multicore systems, disable the TLB flush filter by setting HWCR.FFDIS (bit 6 of
MSR 0xC001_0015).

Fix Planned
No

AMD Opteron

Jelenleg 169-es számnál tartunk.

--
trey @ gépház

Végülis megpróbálhatod elhitetni, hogy a !x86 processzoroknál ilyen tervezési / gyártási hiba nem fordul soha elő, csak az a baj ezzel, hogy ez hazugság lenne. Nekem végülis mindegy, te állíthatsz amit akarsz.

"Es tessek mondani, egyszer majd Processzort is gyartani fognak?"

Nem, nem fognak. Mindenki eldobja majd a gépét (több milliárdról van szó), és helyette amigát, meg pegasos-t fog venni. És visszatérünk a kőkorba. Még az is lehet, hogy pattintok magamnak egy szakócát.

--
trey @ gépház

Mindenki eldobja majd a gépét (több milliárdról van szó), és helyette amigát, meg pegasos-t fog venni.

Hogy is volt a tehenszar, meg a szazmilliard legy esete? De amugy nyugodtan egyel amit akarsz, csak ne haborodj fel, ha az mas szerint szarszagu. :)

És visszatérünk a k?korba. Még az is lehet, hogy pattintok magamnak egy szakócát.

Igen, a PowerPC es a hasonlo processzorok az annyira kokorszak, hogy a vilag leggyorsabb szuperszamitogepeitol az osszes nextgen konzolon at beagyazott kutyuk milliardjaiig mindent hajtanak ami csak letezik. (A "PowerPC has 100% market share on Mars!" meg mar leragott szlogen, ugye...:) Szoval az ilyen kokorszak dumatol talan tartozkodjunk. Oke hogy a te portalod, de azert ne idezzuk mar egy Intel PR trening hangulatat... Ha nem muszaj.

-=- Mire a programozó: "Na és szerintetek ki csinálta a káoszt?" -=-