Nytt säkerhetshål upptäckt i Intel-processorer

Är dock inte övertygad om att denna lösning involverade någon mikrokodförändring, denna tro har jag nog svårt att förändra om inte AMD faktiskt skulle hävda annorlunda, vilket jag inte sett att de gjort (däremot flyter det omkring en massa artiklar som förvirrat kallar AGESA för mikrokod). Detta säger jag enbart iom att det observerbara versionsnumret för mikrokoden inte förändrades från UEFI med AGESA 1.0.0.3AB (sista där RDRAND ej fungerade) till 1.0.0.3ABB (första där RDRAND påstås och ser ut att fungera).
"Microcode Revision 0x8701013" enligt CPU-Z både före och efter fixen.

Men som vi konstaterat, AMD pratar inte något särskilt om varken RDRAND-lösningen i sin helhet eller vad de gjorde för att fixa problemet, så vi vet inga detaljer.

Det jag försökte påpeka är just att problemet du pratar om är större än, och till stor del oberoende av, att AMD gjorde en fix som vi inte vet så mycket om.
Dvs, att det problemet snarast är att vi oavsett fixen inte visste några detaljer om den här svarta lådan som påstås spotta ur sig bra slump, och så hade det ju varit även om RDRAND hade "fungerat" redan vid lansering.
(RDRAND hade ju t.ex. kunnat "fungera" om AMD hade byggt exakt samma chip men skeppat AGESA 1.0.0.3ABB som första version för Ryzen 3000, då hade allting fungerat precis lika bra eller dåligt som nu utan att den här diskussionen hade väckts.)

Rejält sent inlägg då jag är på resande fot.

Har pratat lite med personer hos Bitdefender (de som hittat detta hål), fått lite information av dem samt läst det whitepaper man kan beställa här och gått igenom Linux-patchen.

SwapGS är en form av Spectre variant 1. Det borde i sig kännas rejält olustigt då alla högpresterande CPU-modeller är drabbade av detta, ingen vet hur man på ett vettig sätt kan patcha variant 1 samt det är i praktiken den enda av dessa svagheter som är relevant för "vanliga" användare då den kan utnyttjas via webbläsaren.

Men finns massor med förmildrande omständigheter!

• "gs" är ett x86-specifikt register, segment register G, som är en kvarleva från 16-bitars x86 vilket gjorde det möjligt att adressera mer än 64 kB (16-bitars register kan hålla talet 0-65535 -> 64 k). Som tur är används detta register på ett annat sätt i 32-bitars x86 så swapgs instruktionen finns inte och andra CPU-arkitekturer har ju inte alls denna "finess". Resultat: endast 64-bitars x86 kan drabbas

• swapgs används i nästan varje anrop mot OS-kärnan, därför viktigt denna instruktion är snabb. Men det är trots allt en väldigt liten del av allt som görs vid ett anrop, är därför en instruktion som Intel relativt sent valt att göra lite mer "speciella" optimeringar för. Sandy Bridge och tidigare samt alla Atom-modeller är därför inte mottagliga. Resultat: bara "core" serien från Ivy-Bridge och senare är påverkad.

• Läser man AMDs dokumentation om SwapGS sa den tidigare att swapgs är en synkroniserade instruktion, vilket då helt skulle förklara varför dessa modeller inte är drabbade. Det skulle också betyda att en instruktion som används i nästan varje anrop mot kärnan skulle vara rejält dyr, vilket var märkligt. AMD har sedan ändrat detta, men vidhåller att man ändå inte är påverkade (vilket mycket väl kan stämma givet att bara vissa Intel-modeller är drabbade då man specifikt måste optimera denna instruktion). Resultat: AMD är inte påverkade

• Bara en delmängd av kärnan minne är ens teoretiskt tillgänglig via SwapGS, tyvärr kan man ju inte säga om "rätt/fel" del är tillgänglig

Kör man Windows har man ju redan patchen. Program som spel, Cinebench (ska man tro forumen har vi nu täckt in 99 % av vad folk gör på sin datorer ), Blender, kompilering och annat som är CPU-tungt i själva programmet ser i praktiken noll prestandapåverkan från denna fix.

Phoronix har testat detta. Här får man ha i bakhuvudet att de specifikt har valt ut de fall som i teorin är absolut mest drabbade prestandamässigt av vad Linux-patchen gör. Absolut värsta fallet verkar ligga på 5-6 %, medan de flesta låg på 1-2 %.

Värsta fallet här är program som gör en massiv mängd anrop till OS-kärnan där anropet behöver köra swapgs. Deras värsta fall var att läsa/skriva väldigt små mängder data till en UDP socket (TCP är normalt mindre drabbad då swapgs utgör en mindre andel av totala jobbet som ska utföras per anrop) så många gånger per sekund som var möjligt till det att CPU blir flaskhals (de kör över loopback).

TL;DR blir därför att

• SwapGS är lika ofarlig för normala användare som Spectre variant 2 och Meltdown, d.v.s. JavaScript är inte en attackvektor då man måste kunna köra väldig specifika x86-instruktioner -> behöver tillgång till assembler.

• Prestandamässig lika billig som Spectre variant 1 att fixa i kod.

• Till skillnad från Spectre variant 1 kan SwapGS fixas central i OS (Spectre v1 är riktigt elak i att varje potentiellt drabbad applikation måste patchas)

• Till skillnad från Spectre variat 1 är SwapGS trivial för Intel att fixa i kisel, bara plocka bort optimeringarna vilket gör instruktionen dyrare men säker