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

Permalänk
Medlem
Skrivet av Mordekai:

Det är som sagt inget direkt konstigt att en X86-funktion i en modern processor inte fungerar som den ska, det löses med microcode, men för RDRAND är det viktigt att man vet vilken grad av entropi man kan förvänta sig eftersom funktionen är just till för maximal entropi för att ta fram krypteringsnycklar. Om man nu pekar om RDRAND att använda en annan slumtalsgenerator istället är det viktigt för utvecklare att känna till vilken/hur detta gjorts så att man vet vad man kan förvänta sig io form av prestanda och säkerhet, om man måste skriva en egen implementering unik för Ryzen 3-serien.

Ä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.)

Visa signatur

Desktop: Ryzen 5800X3D || MSI X570S Edge Max Wifi || Sapphire Pulse RX 7900 XTX || Gskill Trident Z 3600 64GB || Kingston KC3000 2TB || Samsung 970 EVO Plus 2TB || Samsung 960 Pro 1TB || Fractal Torrent || Asus PG42UQ 4K OLED
Proxmox server: Ryzen 5900X || Asrock Rack X570D4I-2T || Kingston 64GB ECC || WD Red SN700 1TB || Blandning av WD Red / Seagate Ironwolf för lagring || Fractal Node 304

Permalänk
Medlem
Skrivet av Wikai:

Äsch, är väl bara till att klippa nätverkskabeln och flytta över alla benchprogram & drivrutiner offline.
Har själv nyss gått över från en 6600K till en 3700X så har inte riktigt möjlighet till att ge mig på det

I teorin, ja.

Men det har också skett en hel del fix för Windows 10 i sig, optimeringar och patchningar som är oberoende av dessa buggar. Dessa måste du ju få med, utan att få med Spectre/Meltdown patchningarna.

Permalänk
Medlem
Skrivet av evil penguin:

Ä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.)

Det betyder inte att det inte var microkod, den kan följt med biosuppdateringen.

[edit] Oops, fel av mig missade att du kollat versionen i CPU-Z[/edit]

Permalänk
Medlem

@Ratatosk: ok, tack! :>

Visa signatur

..:: trickeh2k ::..
Windows 11 Pro - Ryzen 7 7800X3D - ASUS TUF B650-PLUS - Kingston FURY Beast DDR5 64GB CL36 - MSI MAG A850GL - MSI RTX 4080 VENTUS 3X OC - Acer Predator XB271HU - ASUS VG248QE - QPAD MK-85 (MX-Brown)/Logitech G PRO Wireless - Samsung 960 EVO 250GB, Samsung EVO 860 500GB, SanDisk Ultra II 480GB, Crucial MX500 1TB, Kingston KC3000 2TB - Steelseries Arctic 5 - Cooler Master Masterbox TD500 Mesh V2

Permalänk
Medlem
Skrivet av evil penguin:

Dvs, det problemet du nu tar upp handlar ju egentligen om att man inte vet hur RDRAND-implementationen fungerar och därmed har begränsade möjligheter att granska lösningen, och det är väl inte egentligen ett större problem nu än om RDRAND "fungerat" redan från början?

Jamen precis. Mig veterligen har inte AMD delgett mycket innan, och ingenting post "fix".
Här är i alla fall en analys av Intels från, om jag såg rätt, Ivy Bridge-version:
https://web.archive.org/web/20141230024150/http://www.cryptog...

Visa signatur

|[●▪▪●]| #Lekburk#: Ryzen 3700X >-< GB-X570-AE >-< 32GB DDR4 >-< MSI RTX 3070 >-< 970 EVO 1TB SSD>--
--< Arctic Freezer 34 >-< FD Define R4 >-< Seasonic F.+ 650W >-< Acer XF270HUA >-< AOC Q2778VQE >--
#Servering#: Ryzen 1700@3,6GHz >-< Prime X470 Pro >-< 16GB DDR4 >-< GTX 1030 >-< 970 EVO 500GB SSD >--
--< Stockkylare >-< Antec P182 >-< Silver Power 600W >-< Samsung 245T |[●▪▪●]|

Permalänk
Medlem
Skrivet av RHWarrior:

Jamen precis. Mig veterligen har inte AMD delgett mycket innan, och ingenting post "fix".
Här är i alla fall en analys av Intels från, om jag såg rätt, Ivy Bridge-version:
https://web.archive.org/web/20141230024150/http://www.cryptog...

Nej, inte vad jag sett heller.
T.ex. denna mer övergripande beskrivning för Ryzen (första generationen) finns ju dock: https://www.amd.com/system/files/TechDocs/amd-random-number-g...

Visa signatur

Desktop: Ryzen 5800X3D || MSI X570S Edge Max Wifi || Sapphire Pulse RX 7900 XTX || Gskill Trident Z 3600 64GB || Kingston KC3000 2TB || Samsung 970 EVO Plus 2TB || Samsung 960 Pro 1TB || Fractal Torrent || Asus PG42UQ 4K OLED
Proxmox server: Ryzen 5900X || Asrock Rack X570D4I-2T || Kingston 64GB ECC || WD Red SN700 1TB || Blandning av WD Red / Seagate Ironwolf för lagring || Fractal Node 304

Permalänk
Medlem
Skrivet av anon12433:

Åtgärder likt dessa är sällan lika effektiva i OS som ändringar i kislet.

Det säger ju inte emot mig på något sätt. Det stämmer fortfarande att om någon leder för att de tar genvägar så ökar de inte sin ledning när de blir påkommna och måste ta samma väg som alla andra. Eller du tycker att det du sa på något sätt motbevisar ovanstående?

Permalänk
Inaktiv
Skrivet av necris:

Det säger ju inte emot mig på något sätt. Det stämmer fortfarande att om någon leder för att de tar genvägar så ökar de inte sin ledning när de blir påkommna och måste ta samma väg som alla andra. Eller du tycker att det du sa på något sätt motbevisar ovanstående?

Jo det gör det, du inser väl att mjukvarufixarna har gjort Intel's CPUer långsammare?

https://www.theverge.com/2018/1/6/16857878/meltdown-cpu-perfo...

Permalänk
Avstängd
Skrivet av Dem8n:

Vafan inte ännu ett säkerhetshål, dags för Intel att göra om designen från grunden. Hoppas att de inte tänkt använda denna designen ändra fram tills att man inte kan krympa mer och satsa på allt krut på nya typer av transistorer. Det är nog minst 8 år innan vi är där. 😩

Skickades från m.sweclockers.com

8 år? Det räcker ju ren 4 år att bygga en ny fabrik, och tror inte de ren forskar i nya transistorer, så lär nog lugnt ta 12-16 år innan vi ser nya typer a transistorer från större tillverkare.

Visa signatur

2600x||16GB @3000Mhz 14-14-10-14-32-46||Vega 64||1TB SSD||HX1000 plat||FD R6 TG vit||CH VII||H100i V2||SST-ARM22SC||SG 32" QHD 144 Hz VA|| https://folding.extremeoverclocking.com/team_summary.php?s=&t...

Permalänk
Datavetare

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

Visa signatur

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

Permalänk
Hjälpsam
Skrivet av Yoshman:

--- Text ---
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.
--- Text ---

Alldeles riktigt, Cinabench är den absolut viktigaste applikationen.

https://twitter.com/bittech/status/1159154112551931904

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

@anon12433: Det var ju precis det jag sa. Om man inte får ta genvägar så blir man långsammare.

Permalänk
Medlem
Skrivet av anon12433:

Jo det gör det, du inser väl att mjukvarufixarna har gjort Intel's CPUer långsammare?

https://www.theverge.com/2018/1/6/16857878/meltdown-cpu-perfo...

Ja, det är ju det jag säger. "Tvingas att sluta ta genvägar" = bli långsammare.

Permalänk
Hjälpsam

Inte konstigt att det finns en massa hål i en halvledare.

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 |