AMD: "Spectre kommer kräva uppdateringar av mikrokoden"

Permalänk
Medlem
Skrivet av Ratatosk:

Hängde inte med här riktigt, menar du att detta problem åtgärdas genom att ändra något annat, som också kallas mikrokod?
Det handlar mer om att slå av eller på olika funktioner, inte hur man exekverar "CISC" genom ett antal "RISC""?
Min kunskap är inte purfärsk.

Flera av de enheter i processorn som inte direkt exekverar instruktioner utan förbereder dem, så att säga, kan programmeras om så att de beter sig på ett annat sätt. Detta görs genom så kallad mikrokod, vilken måste laddas in i processorn varje gång den startar (antingen från OSet eller från BIOS). I nästan alla fall handlar det om en optimering som måste stängas av eftersom det är ett problem med den, men här är det alltså lite mer komplicerat.

Samma ord används för att beskriva när en x86-instruktion måste få ett helt litet program för att kunna exekveras, vilket är en annan sak. Det är lite olyckligt att det är samma ord för två olika saker, men det är samma på engelska. Skyll på Intel-

Visa signatur

5900X | 6700XT

Permalänk
Inaktiv
Skrivet av anon114264:

Varför skulle Intel eller AMD-användare vilja få prestanda som en Intel MMX-processor från 1997?

För de flesta är det lugnt. Spel och liknande påverkas väldigt lite (enstaka %). Däremot är det värre om det man gör kräver en massa I/O operationer. Även då blir det klart värre för Intel ägare då AMD inte är känslig för meltdown och inte heller för en av spectre varianter. Den kvarvarande verkar kräva ändringar i hårdvaran för att lösa helt så patchande är inte helt nödvändigt (viktigaste är att browsern patchas).

Permalänk
Medlem
Skrivet av knge:

De kändes allt lite arroganta med sina tvärsäkra uttalanden om att deras processorer var immuna.

Var har AMD påstått att Spectre inte gäller även dem? Faktum är att AMD har varit ganska klara med att version två av spectre är något processorn är känslig emot även om det gäller "near zero". Meltdown har man däremot menat att Ryzen är immun emot. Vilket i sig inte är omöjligt.

Visa signatur

Fractal Design Meshify 2 Compact w/ Dark Tint | Intel i5 12600K | Asus ROG Strix B660-F | 32 GB Corsair DDR5 5600 MHz CL36 | MSI Geforce RTX 3060 TI Ventus 2X OCV1 | 512 GB Samsung Pro 850 SSD + 2TB WD Black SN850 NVME PCI-E 4.0 | Corsair RM750X |

Permalänk
Skrivet av knge:

De kändes allt lite arroganta med sina tvärsäkra uttalanden om att deras processorer var immuna.

Detta är falskt, AMD har redan från början varit mycket klara med att v 1 och v 2 av spectre kan påverka deras processorer medan v 3 aka meltdown inte inte gör det.

https://www.amd.com/en/corporate/speculative-execution

Permalänk
Medlem
Skrivet av Xinpei:

Var har AMD påstått att Spectre inte gäller även dem? Faktum är att AMD har varit ganska klara med att version två av spectre är något processorn är känslig emot även om det gäller "near zero". Meltdown har man däremot menat att Ryzen är immun emot. Vilket i sig inte är omöjligt.

Fick gå tillbaka till själva uppsatsen om Spectre för att försöka begripa vad som händer. Spectre 1 förklarade jag efter bästa förmåga här

#17203425

men Spectre 2 uppfattade jag inte omedelbart att det var ett annat hål. I uppsatsen så är det bara Spectre 1 som beskrivs i detalj, men Spectre 2 tas upp under "discussion". Den biten orkade jag inte läsa förra gången, och den är inte speciellt detaljerad, men det är alltså så här det fungerar.

En direkt branch ser ut som "om A=0, hoppa 20 bytes framåt". En indirekt branch ser ut som "om A=0, hoppa 20+X bytes framåt". Att man kan förutsäga att branchen skall tas hjälper inte, utan man måste också förutsäga vart man skall hoppa. Detta görs genom en så kallad BTB, branch target buffer. För varje branch i koden, lagrar processorn vart den branchen går till i en tabell. Spectre 2 går ut på att en process kan fylla BTBn med gissningar som gör att branch predictorn gissar fel när den kör en annan process.

För Intel går det till så här: BTBn anger inte hela adressen för den branch som förutsägs. Jag kan inte få fram riktigt exakt vad de lagrar. Någon föreslog att den helt enkelt skippade antingen de första eller de sista siffrorna av adressen, så att tabellen helt enkelt säger "om det ligger en branch på en adress som slutar på 456, så brukar den gå 28 bytes framåt", men det verkar inte som om det är så enkelt. Oavsett hur det går till, så är det i alla fall så att man ganska lätt kan fylla BTBn för en viss branch med förutsägelser.

Exploiten går ut på att man räknar ut var kerneln har en viss indirekt branch, placerar en egen branch i sin kod så att dessa använder samma rad i BTBn, kör sin egen branch en massa gånger för att fylla BTBn med en viss adress, och gör något som tvingar sedan kerneln att köra sin indirekta branch. Branch predictorn gissar fel, processorn börjar exekvera kod i kerneln på helt fel ställe, och angriparen kan genom att läsa i cachen räkna ut vilken data processorn jobbade med när den gissade fel. På så sätt läcker man data från kerneln.

Poängen är att Zen inte har en BTB som fungerar på alls samma sätt. Det verkar inte finnas någon aliasing att utnyttja, utan hela adressen lagras. Överhuvudtaget är branch predictorn mycket enklare. AMD har plockat predictorn från Bobcat-kärnan (alltså de små processorerna som bland annat PS4 och Xbox One använder) istället för den komplexa från Bulldozer.

Detta gör att det inte finns något lätt sätt att fylla BTBn med felaktiga gissningar. Om någon skulle kunna komma på ett sätt att fylla BTBn med gissningar så skulle Spectre 2 fungera även på Zen, men just nu är det ingen som har någon metod för det.

Däremot verkar det som om Bulldozer kan vara sårbar för Spectre 2 - om någon nu behövde ytterligare anledning att byta bort den processorn.

Visa signatur

5900X | 6700XT

Permalänk
Hjälpsam
Skrivet av mpat:

Flera av de enheter i processorn som inte direkt exekverar instruktioner utan förbereder dem, så att säga, kan programmeras om så att de beter sig på ett annat sätt. Detta görs genom så kallad mikrokod, vilken måste laddas in i processorn varje gång den startar (antingen från OSet eller från BIOS). I nästan alla fall handlar det om en optimering som måste stängas av eftersom det är ett problem med den, men här är det alltså lite mer komplicerat.

Samma ord används för att beskriva när en x86-instruktion måste få ett helt litet program för att kunna exekveras, vilket är en annan sak.

Tack då vet jag.

Citat:

Det är lite olyckligt att det är samma ord för två olika saker, men det är samma på engelska. Skyll på Intel-

Alltid denna jädra Intel!

Visa signatur

AMD Ryzen 7 1700 | Saphire RX 5700 Pulse XT (Silent Mode) | 64 GB Kingston ECC | https://valid.x86.fr/z2ljhr | Stockkylaren | Bitfenix Whisper M 750W.
AMD Ryzen 9 5900X | AMD RX 5700 | 64 GB Micron ECC | https://valid.x86.fr/5krwxf
HTPC | https://valid.x86.fr/uuzli0 |

Permalänk
Medlem

Ska bli intressant om framtida Zen 2, som troligtvis kommer bli Ryzen 3xxx serien kommer vara immun mot Spectre 1 och 2.

Även innan jag hörde om Spectre och Meltdown så har det varit en del saker som jag tycker AMD gjort bra med Ryzen.
Men att det inte varit tillräckligt stor anledning för att byta ut min i7 mot en Ryzen.
Nu har AMD varit bättre med Spectre och Meltdown, även om de inte heller är immuna mot Spectre.
Så där är det ännu en anledning att "byta lag", även om det kanske fortfarande inte är tillräckligt stor anledning nu när Ryzen också är drabbade.
Zen 2 borde ha förbättringar i IPC och/eller klockfrekvenser, så att de är snabbare än dagens Zen, även om Spectre aldrig dykt upp.
Har de dessutom fixat så de är immuna mot Spectre utan att tappa massa prestanda så kommer det bli väldigt intressant med Zen 2.

Men först ska Zen+ komma i vår. Så det dröjer väl innan Zen 2 finns ute.

Permalänk
Hjälpsam

"We have seen some initial stories with a couple of inaccuracies so want to make sure we are being perfectly clear.

* There is no change to AMD’s position on our susceptibility to GPZ Variant 1 or GPZ Variant 2 (collectively called Spectre in many news reports).
* The update in relation to Variant 2 is that even though Variant 2 has not been demonstrated to work on AMD products due to differences in our micro architecture, out of an abundance of caution we are making optional micro code updates available to further contain the threat.

Again, to make it perfectly clear we have not changed our statement erlated to our susceptibility to Variant 2. Let me know if you have questions or need additional details."
https://www.hardocp.com/news/2018/01/11/amd_doubles_down_on_p...

Visa signatur

AMD Ryzen 7 1700 | Saphire RX 5700 Pulse XT (Silent Mode) | 64 GB Kingston ECC | https://valid.x86.fr/z2ljhr | Stockkylaren | Bitfenix Whisper M 750W.
AMD Ryzen 9 5900X | AMD RX 5700 | 64 GB Micron ECC | https://valid.x86.fr/5krwxf
HTPC | https://valid.x86.fr/uuzli0 |

Permalänk
Datavetare

@mpat: huruvida Intel hade delat med sig data kring Haswells BTB (var främst Haswell som används av forskarna för proof-of-concept) är en rätt akademisk fråga då man redan hade gjort "reverse engineering" på Haswells BTB senast hösten 2016 (det hittades bl.a. en svaghet i Haswell BTB då som påverkade effektivitet av ASLR). D.v.s. där hade man redan erforderlig information.

En bättre jämförelse är då AMD och ARM. ARM, AMD och Intel fick alla redan på detta problem i somras. Forskarna hade varken erforderlig information kring BTB för vare sig ARMs eller AMDs kretsar. ARM valde att inte heller dela implementationsspecifika detaljer.

Under det ca halvår man haft på sig har man internt på ARM tittat på hur de olika designerna man har kan tänkas attackeras, varför har inte AMD gjort detta (för hade man det hade man kunnat säga hur det ligger till, inte köra med "near zero...")?

Överhuvudtaget har ARM (menar då Cortex, Samsung och Qualcomm har inte sagt speciellt mycket så här långt) hållit guldstandarden för hur man (i alla fall sett från en ingenjörs håll) bör hantera detta: d.v.s. ingen bullshit PR, väldigt bra teknisk information som visar att man har gjort hemläxan kring exakt vilka kretsar som är mottaglig samt hur de olika kretsarna kan attackeras vilket därmed också ger betydligt bättre insikt i hur man kan stoppa attackerna.

Intel har en blandning av "damage control" från PR (som man som ingenjör kan ha en hel del åsikter om) men man har även väldigt bra tekniska analyser, ger en väldigt bra bild av hur olika kretsar är drabbade hade en mikrokod-patch ute redan inne

Möjligen vet AMD mycket mer än vad man nu visar utåt, de borde i så fall börja följa Intels och ARMs exempel kring de tekniska bitarna. För just nu ser det mycket ut som man tagit hållningen: vi hoppas det inte är så illa för oss som för övriga.

Just Spectre Variant 2, man pekar på att ingen gjort en fungera attack än. Det har inte forskarna gjort för ARM heller, men ARM själva vet hur man gör.

D.v.s. det har aldrig varit frågan om det finns en svaghet. Alla CPUer som är mottaglig för något av dessa tre svagheter är mottagliga för Variant 2, finns eventuellt vissa ARM som klarar sig från Variant 1 men ändå är mottagliga för Variant 2. Så känns det sannolikt att Zen eventuellt klarar sig från Variant 2?

Var är det här för b-ll?

"The update in relation to Variant 2 is that even though Variant 2 has not been demonstrated to work on AMD products due to differences in our micro architecture, out of an abundance of caution we are making optional micro code updates available to further contain the threat."

Nähä, men ni har alla detaljer kring mikroarkitekturen så varför har inte ni demonstrerat att attacken endera kan göras (finns inga krav på att publicera hur man ska göra) alt. visat att den inte är möjlig (det bör man publicera om det ska vara trovärdigt + detta vore väldigt positivt för AMD då fixarna för Variant 2 har tyvärr visat sig ha rätt hög kostnad)? Är väldigt få kretsar där det finns proof-of-concept för Variant 2 just nu.

Edit: om jag fick gissa skulle gissa kring hur Intel skulle hanterea information kring BTB så är det att man inte skulle ge ut mer information än vad man redan har i deras "Intel 64 and IA-32 Architectures Optimization Reference Manual" (som är de anser är vad man behöver veta för att t.ex. göra en kompilator).

Visa signatur

Care About Your Craft: Why spend your life developing software unless you care about doing it well? - The Pragmatic Programmer

Permalänk
Medlem

@Yoshman: Rent matematiskt måste det gå att göra en BTB som inte kan utnyttjas - rent trivialt måste man kunna göra en BTB som inte har några alias utan bara listar de senaste x målen för de senaste y brancharna, identifierade antingen per fysisk minnesadress eller per virtuell minnesadress med fullständig PCID. En sådan som jag beskriver skulle vara ineffektiv, så Intel har genat i hörnena, vilket ledde til Spectre 2. Om AMD nu tror att de har gjort en predictor som inte går att utnyttja och som är effektiv nog att vara praktisk, så vill de inte dela med sig om hur den fungerar. Sådant är affärshemligheter. Det är inte optimalt för oss, men å andra sidan: folk har anat i åtminstone ett år att något form av attack som använder data om cache-access skulle gå att genomföra - Hacker News har snackat om det åtminstone så länge, och det är inte direkt som att det är Black Hat-bladet eller nåt sånt. Man hade kunnat säga att alla skulle stänga av all cache för att vara på den säkra sidan. Det var det naturligtvis ingen som gjorde, för det hade blivit alltför långsamt. Detta är nästan samma situation: man kan kanske göra ett angrepp mot BTBn i Zen, men ingen vet hur. Om det en dag kommer ett angrepp mot BTBn i ZEN, så finns patcharna klara att rulla ut.

Skickades från m.sweclockers.com

Visa signatur

5900X | 6700XT

Permalänk
Hjälpsam

Arstechnica skriver lättläst och initierat.
https://arstechnica.com/gadgets/2018/01/heres-how-and-why-the...

Visa signatur

AMD Ryzen 7 1700 | Saphire RX 5700 Pulse XT (Silent Mode) | 64 GB Kingston ECC | https://valid.x86.fr/z2ljhr | Stockkylaren | Bitfenix Whisper M 750W.
AMD Ryzen 9 5900X | AMD RX 5700 | 64 GB Micron ECC | https://valid.x86.fr/5krwxf
HTPC | https://valid.x86.fr/uuzli0 |

Permalänk
Datavetare
Skrivet av mpat:

@Yoshman: Rent matematiskt måste det gå att göra en BTB som inte kan utnyttjas - rent trivialt måste man kunna göra en BTB som inte har några alias utan bara listar de senaste x målen för de senaste y brancharna, identifierade antingen per fysisk minnesadress eller per virtuell minnesadress med fullständig PCID. En sådan som jag beskriver skulle vara ineffektiv, så Intel har genat i hörnena, vilket ledde til Spectre 2. Om AMD nu tror att de har gjort en predictor som inte går att utnyttja och som är effektiv nog att vara praktisk, så vill de inte dela med sig om hur den fungerar. Sådant är affärshemligheter. Det är inte optimalt för oss, men å andra sidan: folk har anat i åtminstone ett år att något form av attack som använder data om cache-access skulle gå att genomföra - Hacker News har snackat om det åtminstone så länge, och det är inte direkt som att det är Black Hat-bladet eller nåt sånt. Man hade kunnat säga att alla skulle stänga av all cache för att vara på den säkra sidan. Det var det naturligtvis ingen som gjorde, för det hade blivit alltför långsamt. Detta är nästan samma situation: man kan kanske göra ett angrepp mot BTBn i Zen, men ingen vet hur. Om det en dag kommer ett angrepp mot BTBn i ZEN, så finns patcharna klara att rulla ut.

Skickades från m.sweclockers.com

Fast AMD tror uppenbarligen inte det, var man säker på att det inte gick att utnyttja skulle man knappast lägga resurser på att ta fram en mikrokoduppdatering. Framförallt inte då skyddet mot Spectre Variant 2 har visat sig ha rätt rejäl prestandapåverkan, i vissa fall i nivå med Meltdown-fixen utan PCID/INVPCID optimeringar.

Finns ingen anledning att AMD skulle ge ut designhemligheter, varken Intel eller ARM har gjort det. Vad som förväntas är att varje kretstillverkare, som har alla erfoderliga detaljer, gör hemläxan kring detta på sin kammare om man inte vill ge forskarna de tekniska detaljerna.

Under det halvår som gått kan man börja ställa sig frågan: vad har AMD gjort?

Nyheten om detta fick släppas ungefär en vecka för tidigt. Ändå kunde ARM (och även Intel) redan dag ett skicka ut teknisk dokumentation som

  • beskrev exakt vilka kretsar som är påverkade av vad

  • ARM har tre separata serier av Cortex A (de enkla A7, A53, A55 som inte påverkas. De perf/W optimerade A9, A12, A17, A73 som påverkas av Spectre. High-end som även påverkas av en variant av Meltdown A15, A57, A72, A75), första dagen listade man precis vilka Linux-patcher som bör installeras för varje krets samt man hade mikrokoduppdateringar klara (Intel hade också mikrokoden klar + Linux patcharna var färdiga)

Tekniskt sett har både ARM och Intel skött detta lysande (att man har buggar är naturligtvis dåligt, pratar om hur man hanterat "after-the-fact").

Intel har haft en del bull-PR. Grejen är att AMD endast haft bull-PR så här långt, de har inte gjort något tekniskt relevant (artikeln vi kommenterar indikerar i.o.f.s. att man nu jobbar på det tekniska, väldigt positivt!).

Varför har inte ens AMD lurat exakt vad man är mottaglig för? Är ju lite märkligt att vara den som rent tekniskt klarar sig klart bäst (man är helt opåverkad av Meltdown) men ändå har man inte ens lurat ut om man är mottaglig för Variant 2 (om man vet att man är mottaglig, varför hade man inte mikrokoden klar redan?).

Om AMD väntar till att det finns dokumenterad attacker mot Epyc innan man rullar ut patchar är man en död leverantör till enterprisemarknaden. Som aktieägare i AMD hoppas jag innerligt att man inte är så korkad.

Visa signatur

Care About Your Craft: Why spend your life developing software unless you care about doing it well? - The Pragmatic Programmer

Permalänk
Medlem
Skrivet av Yoshman:

Fast AMD tror uppenbarligen inte det, var man säker på att det inte gick att utnyttja skulle man knappast lägga resurser på att ta fram en mikrokoduppdatering. Framförallt inte då skyddet mot Spectre Variant 2 har visat sig ha rätt rejäl prestandapåverkan, i vissa fall i nivå med Meltdown-fixen utan PCID/INVPCID optimeringar.

Skyddet mot Spectre version 2 är tvådelat. Man måste göra en uppdatering av microcode först, och sedan måste programmet uppdateras för att skicka kommandot att ställa om hur branch predictorn fungerar. Vad AMD gör nu, är att göra uppdateringen av microcode för att göra dessa nya lägen för branch predictorn tillgängliga. Så länge man tror att deras processorer inte påverkas, behöver det speciella kommandot för att ställa om predictorn inte skickas, men om det en dag visar sig att det finns ett hål så går det lätt att täppa till det genom en programvaruuppdatering. Speciellt för Amazon, Google, MS osv som har stora moln att underhålla, är detta att föredra - de kan göra vad de kan nu, och sedan låta kunderna bestämma hur de vill konfigurera de program de kör.

Citat:

Finns ingen anledning att AMD skulle ge ut designhemligheter, varken Intel eller ARM har gjort det. Vad som förväntas är att varje kretstillverkare, som har alla erfoderliga detaljer, gör hemläxan kring detta på sin kammare om man inte vill ge forskarna de tekniska detaljerna.

Under det halvår som gått kan man börja ställa sig frågan: vad har AMD gjort?

Det har gått ett halvår sedan Intel, ARM och AMD (ingen annan - inte Apple, inte MS, inte ens Android-divisionen av Google) informerades om Spectre 1. Hur länge någon har känt till Spectre 2 är oklart. Det kan mycket väl vara så att den informationen enbart gick till Intel, om den nu sågs som en Intel-specifik bugg. Om du inte läst uppsatsen om Spectre, så kan jag rekommendera det.

https://spectreattack.com/spectre.pdf

Det mest intressanta börjar under 1.2. Texten om Spectre 1, rubrik "Exploiting conditional branches", är lättfattlig och innehåller pseudokod för att förklara hur det går till. Spectre 2 beskrivs betydligt mer luddigt under "Exploiting indirect branches". Det talas om att angriparen kan träna BTBn att gissa fel, utan att överhuvudtaget nämna hur denna träning går till. Diskussionen fortsätter under 5, "Poisoning Indirect Branches", och exemplen är under 5.1. De talar bara om Haswell och Skylake, och de säger t.o.m att "Testing on non-Intel CPUs has not been performed". Om exemplen i artikeln nu inte går att använda på AMD, är inte AMD immuna mot Spectre 2? Formulerat på ett annat sätt - om någon lyckas komma på ett sätt att manipulera BTBn på Zen, är inte det då ett nytt angrepp som borde få ett nytt flashigt namn?

Citat:

Nyheten om detta fick släppas ungefär en vecka för tidigt. Ändå kunde ARM (och även Intel) redan dag ett skicka ut teknisk dokumentation som

  • beskrev exakt vilka kretsar som är påverkade av vad

  • ARM har tre separata serier av Cortex A (de enkla A7, A53, A55 som inte påverkas. De perf/W optimerade A9, A12, A17, A73 som påverkas av Spectre. High-end som även påverkas av en variant av Meltdown A15, A57, A72, A75), första dagen listade man precis vilka Linux-patcher som bör installeras för varje krets samt man hade mikrokoduppdateringar klara (Intel hade också mikrokoden klar + Linux patcharna var färdiga)

Tekniskt sett har både ARM och Intel skött detta lysande (att man har buggar är naturligtvis dåligt, pratar om hur man hanterat "after-the-fact").

Intel har haft en del bull-PR. Grejen är att AMD endast haft bull-PR så här långt, de har inte gjort något tekniskt relevant (artikeln vi kommenterar indikerar i.o.f.s. att man nu jobbar på det tekniska, väldigt positivt!).

Varför har inte ens AMD lurat exakt vad man är mottaglig för? Är ju lite märkligt att vara den som rent tekniskt klarar sig klart bäst (man är helt opåverkad av Meltdown) men ändå har man inte ens lurat ut om man är mottaglig för Variant 2 (om man vet att man är mottaglig, varför hade man inte mikrokoden klar redan?).

Som jag läser texten har ingen hittills lyckats manipulera BTBn på Zen. AMD tror sig därför vara immuna. Så varför säger man då inte det? Sannolikt för att det skulle kunna finnas ett sätt att manipulera BTBn. Man uttrycker sig försiktigt. Samma sak gjorde ARM - idag säger de att det bara är A75 som påverkas av Meltdown, medan det tidigare var en längre lista som du skriver ovan.

Intel's agerande har varit långt från felfritt. De har konsekvent försökt få detta att framstå som ett fel för att hela branchen, när det värsta felet (Meltdown) var i princip enbart Intel - A75 finns inte i någon produkt på marknaden än, och ingen har lyckats angripa Apples kärnor om de nu eventuellt har en svaghet (något man bara kan gissa sig till från formuleringen av patch notes till iOS).

Att sen deras VD säljer aktier mitt under hela soppan hjälper ju inte direkt att få dem att framstå i god dager.

Citat:

Om AMD väntar till att det finns dokumenterad attacker mot Epyc innan man rullar ut patchar är man en död leverantör till enterprisemarknaden. Som aktieägare i AMD hoppas jag innerligt att man inte är så korkad.

Då är det väl tur att man rullar ut ny microcode nu? Att ändra på programnivå så att man använder Intel-koden också på AMD-processorer är ju trivialt om man en dag måste göra det.

(Om vi nu meddelar världen om vilka aktie-innehav vi har, så kan jag säga att jag inte äger några aktier i vare sig Intel, AMD, Apple, MS, ARM eller någon annan som är inblandad i den här soppan)

Visa signatur

5900X | 6700XT

Permalänk
Hjälpsam

AMD har sagt att deras uppdatering av mikrokod är valfri.

Skrivet av AMD om Spectre:

AMD will make optional microcode updates available to our customers and partners for Ryzen and EPYC processors starting this week. We expect to make updates available for our previous generation products over the coming weeks.

Arkitekturen är en annan.

Skrivet av AMD om Spectre:

Differences in AMD architecture mean there is a near zero risk of exploitation of this variant. Vulnerability to Variant 2 has not been demonstrated on AMD processors to date.

https://www.amd.com/en/corporate/speculative-execution.

Jag antar att AMD känt till angreppet ganska länge och att de inte kunnat vaska fram något från kärnan.
Om man nu utgår från att AMD inte är idioter, bör vad de säger stämma.

Det som också talar för det, är att Intel inte kunnat påvisa någon form av lyckat intrång på en Zen, någon som tror att de inte har försökt?

Vidare.
"Why no IBRS on Zen? AMD argues that Zen's new branch predictor isn't vulnerable to attack in the same way. Most branch predictors have their own special cache called a branch target buffer (BTB) that's used to record whether past branches were taken or not. BTBs on other chips (including older AMD parts, Intel chips, ARM's designs, and Apple's chips) don't record the precise addresses of each branch. Instead, just like the processor's cache, they have some mapping from memory addresses to slots in the BTB. Intel's Ivy Bridge and Haswell chips, for example, are measured at storing information about 4,096 branches, with each branch address mapping to one of four possible locations in the BTB.

This mapping means that a branch at one address can influence the behavior of a branch at a different address, just as long as that different address maps to the same set of four possible locations. In the Spectre attack, the BTB is primed by the attacker using addresses that correspond to (but do not exactly match with) a particular branch in the victim. When the victim then makes that branch, it uses the predictions set up by the attacker.

Zen's branch predictor, however, is a bit different. AMD says that its predictor always uses the full address of the branch; there's no flattening of multiple branch addresses onto one entry in the BTB. This means that the branch predictor can only be trained by using the victim's real branch address. This seems to be a product of good fortune; AMD switched to a different kind of branch predictor in Zen (like Samsung in its Exynos ARM processors, AMD is using simple neural network components called perceptrons), and the company happened to pick a design that was protected against this problem."
https://arstechnica.com/gadgets/2018/01/heres-how-and-why-the...

Visa signatur

AMD Ryzen 7 1700 | Saphire RX 5700 Pulse XT (Silent Mode) | 64 GB Kingston ECC | https://valid.x86.fr/z2ljhr | Stockkylaren | Bitfenix Whisper M 750W.
AMD Ryzen 9 5900X | AMD RX 5700 | 64 GB Micron ECC | https://valid.x86.fr/5krwxf
HTPC | https://valid.x86.fr/uuzli0 |

Permalänk
Medlem
Skrivet av Ratatosk:

In the Spectre attack, the BTB is primed by the attacker using addresses that correspond to (but do not exactly match with) a particular branch in the victim.

Spelar det så stor roll? Även om branch predictorn använder hela adressen kan väl attackern också använda den exakta adressen. Om man försöker exploatera från javascript kan det bli svårt men i vanlig C kan man i linux använda mmap() med MAP_FIXED för att få en mappning av vilken typ som helst var som helst.

Permalänk
Hjälpsam
Skrivet av Emaku:

Spelar det så stor roll? Även om branch predictorn använder hela adressen kan väl attackern också använda den exakta adressen. Om man försöker exploatera från javascript kan det bli svårt men i vanlig C kan man i linux använda mmap() med MAP_FIXED för att få en mappning av vilken typ som helst var som helst.

Hur skall man enkelt få tag på och använda adressen man är ute efter?
I Intels fall kan man använda adresser, som inte helt matchar den man är ute efter, i AMD är man tvungen att använda exakt rätt adress.

edit måste erkänna att jag har en rätt luddig uppfattning om hur Spectre fungerar, så visst, du kanske vet något jag inte vet.

Visa signatur

AMD Ryzen 7 1700 | Saphire RX 5700 Pulse XT (Silent Mode) | 64 GB Kingston ECC | https://valid.x86.fr/z2ljhr | Stockkylaren | Bitfenix Whisper M 750W.
AMD Ryzen 9 5900X | AMD RX 5700 | 64 GB Micron ECC | https://valid.x86.fr/5krwxf
HTPC | https://valid.x86.fr/uuzli0 |

Permalänk
Medlem
Skrivet av Ratatosk:

Hur skall man enkelt få tag på och använda adressen man är ute efter?

Det beror på vilken typ av offer man är ute efter. Om offret inte använder ASLR så ligger koden alltid på samma adress. Det är ganska nyligen som linux distributioner började använda PIE för alla körbara filer. Gentoo började använda PIE för 2 månader sedan och många LTS distributioner har det troligen inte. Spectre 2 kan också i teorin användas för att attackera koden i UEFI för att läcka allt fysiskt minne. UEFI runtime services koden ligger på samma adress varje boot och det är inte troligt att moderkort tillverkarna kommer kompilera om all firmware för att skydda mot Spectre 2.

Om offret använder ASLR behöver man någon annat sätt att få tag på adressen. Intel BTB använder tydligen bara de lägsta 31 bittarna av adressen så om ASLR inte randomiserar de lägsta 31 bittarna tar de ut varandra. Spectre rapporten nämnde att windows ASLR inte randomiserar bits 15..0 så de tar delvis ut varandra men inte helt. För de övriga bittarna behöver man något annat sätt.

Den mest intressanta attacken med Spectre 2 var att man kan läsa kärnans minne med den (även om pti används). För att göra det måste man veta var kerneln ligger och KASLR lägger kerneln på ny adress varje boot. Tyvärr är linux KASLR inget vidare och ger bara runt 10-bit entropi.

Med spectre 2 kan en attacker manipulera BTB så att ett offer gör speculative execution av fel adress men samma sak funkar också baklänges. När ett offer kör kod manipuleras BTB vilket gör att en attackers kod gör speculative execution vilket kan mätas. På så vis kan en attacker ta reda på vilken info offret lämnade i BTB, däribland vilken adress offrets kod kördes från. Googles project zeros PoC för spectre 2 använde den tekniken för att hitta den fysiska adressen för host kerneln från en virtual maskin. Aliasing I Intels BTB gjorde att söktiden kortades ner med en faktor av 16 men eftersom kernel ASLR har så låg entropi ändå spelar det ingen roll.

Även med vettig KASLR så behöver man bara en infoleaks för få adressen. Infoleak vulnerability är troligen den vanligaste typen av säkerhetsbuggar i linux kärnan. Det hittas en bunt varje månad.