Otazka je, jestli procesory od AMD jsou na tom lepe. Ne, ze by byly nejak vyrazne jednodussi, nez ty od Intelu a tak s klidem take mohou obsahovat chyby.
Na druhou stranu si nepamatuji, a ani jsem teď rychle na internetu nenašel, že by procesory AMD někdy v minulosti měly podobný problém. Intel měl f00f (a další - např. FDIV bug) a například Cyrix měl coma bug, který také způsobil "zatuhnutí" procesoru.
To není bug, to je featura. Zkrátka se jí povedlo udělat toho hypervizora trošku schopnějšího než normálně. Je to využití virtualizace: http://en.wikipedia.org/wiki/Blue_Pill_(malware)
Já nevím jestli jste ten odkazovaný článek četl, ale tam se píše, že to je obecně chyba hardware-base hypervizorů (tj. to samé platí pro Intel) pro virtualizaci a také je k tomu potřeba kompromitovat hostitelský systém.
Na AMD existuje prototyp a nikoli exploit. Každopádně "bluepill" není chyba (tak jak se o chybách tady bavíme, tj. způsobí zatuhnutí procesoru a podobně), ale vlastnost libovolného virtualizačního systému. Můžeme se bavit o tom, že to byla chyba v návrhu, ale jak jde vidět z rozhovoru s Anthony Liguori, tak to nebude tak žhavé, jak to vypadá.
No třeba u starších Athlonů poločíselný poměr kmitočtů sběrnice procesoru a FSB způsoboval občasné vytuhnutí procesoru při přechodu do úsporného režimu. Přetaktování na celočíselný poměr to vyřešilo. Tuším, že tehdy měla errata procesoru asi 16 položek.
K6 a K6-2 jde taky shodit, viz. "Code Segment Limit Violation Check Associated with Dual-decoded Instructions" v revision guide na stránkách AMD. I jsem viděl kód a reálné shození procesoru. Opterony až do revize "D" jdou taky zatuhnout pomocí SSE instrukcí, errata 105.
"Na druhou stranu si nepamatuji, a ani jsem teď rychle na internetu nenašel, že by procesory AMD někdy v minulosti měly podobný problém. Intel měl f00f (a další - např. FDIV bug) a například Cyrix měl coma bug, který také způsobil "zatuhnutí" procesoru."
Okamžitě mě napadne velmi závažný (byť AMD a jejich zastánci bagatelizovaný) a hodně drsný bug - chyba v TLB.