Kritisk sårbarhet i Intel-processorer funnen

Jaha då kan man vänta sig ännu slöare prolle snart då när intel/ms patchar.. fanns ju nåt program som hette Inspectre vilket kunde stänga av spectre och meltdown firmware som gjorde prollen snabbare igen men det verkar inte vara aktuellt längre..
Någon som vet om det finns nåt nyare program ute som gör samma sak fast med fler nyare vulnerabilities?

Man kan ju få mjukvaruuppdateringar i Windowsupdate med eller? jag fick iaf spectre och meltdown fixar och jag har aldrig uppdaterat bios på den här datorn

(Q) What is the overhead for the mitigation?

(A) This depends on whether Gather is in the critical execution path of a program. According to Intel, some workloads may experience up to 50% overhead.

Förstår ju varför Intel infört bug-bounties när de nu får en ursäkt att drastiskt kapa prestandan på gamla saker utan att bli klandrade för s.k. planned obsolescence.

Man förstår även varför det var så svårt för AMD att ärligt slå Intel i ren prestanda under just denna tidsperiod. Känns som Intel la allt krut på att maximera prestandan utan att tänka alls på säkerheten. Det är ju inte första gången denna typ av kritisk sårbarhet kopplad till spekulativ exekvering upptäcks i Intel-processorer från denna epok, med tillhörande prestandaförlust på 30-50% efter mitigation.

Kanske vore intressant med ett uppdaterat test för att se om det påverkar..

Rätt absurt att hårdvarutillverkare kan skicka ut en uppdatering som sänker prestandan med 50%. Tänk om en biltillverkare hade gjort likadant, "vi upptäckte en defekt med den här bilmodellen som kan uppstå vid höga hastigheter, så vi har skickat ut en OTA-uppdatering som begränsar den till 60 km/h så nu är problemet åtgärdat".

Borde vara återkallelse som gäller.

Nästan i stil med Apples iPhone-nedklockning-skandal

Skylake måste ju vara peak av ’rotten blue wine’ eller något. Fullt av arkitektoniska fusk och svagheter

"Dieselgate" är inte så länge sedan, så det har hänt och folk var verkligen inte glada.

typ, dock har AMD precis drabbats av en egen grej nu som kallas Inception och som drabbar Zen3 och Zen4

Amen på det! Test med olika generationers CPU, gärna med olika grader av ''vulerabilityfixes'' för att se vilka som reducerat prestandan mest etc. Mycket jobb kan jag tänka mig men också väldigt intressant och säkert efterfrågat av fler än mig

Phoronix har gjort en del prestandatester nu för att se hur mycket det påverkar. Notera dock att det är AVX2/AVX-512 GATHER-instruktionen som är problemet, så det är bara mjukvara som använder den instruktionen på ett prestandakritiskt sätt som påverkas. D.v.s. det är ingen generell prestandaförsämring utan något som bara påverkar specifika program.

Det är konvention att man underrättar hårdvarutillverkaren och håller tillbaka offentliggörandet tills dess att det rimligen skulle kunna finnas en lösning där ute.

Wikipedia: Coordinated vulnerability disclosure

Om det är återkallade på 50 %, vad ska man då göra med Inception?

"To fully mitigate Inception, the branch predictor state has to be fully flushed while switching between distrusting contexts. We found that on Zen 1(+) and Zen 2, this comes with a hefty overhead between 93.1% and 216.9%, depending on the specific microarchitecture."

För att få till matten här: 100 % overhead -> 50 % prestanda, så 216,9 % overhead -> 32 % prestanda...

Det man måste inse att det inte i något av fallen betyder att något verkligt fall kommer i närheten av att se en sådan prestandaminskning. Det är absolut worst-case för ett fall som inte gör något annat än kör specifikt just det som påverkas av buggen.

Det unika med Downfall är att det påverkar "compute-bound" applikationer, d.v.s en applikation som inte alls gör speciellt många OS-anrop / kontex-switchar kan ändå se en rätt kraftig påverkan!

Nästan alla andra fall, inklusive Inception (det är variant av tidigare Retbleed), påverkar primärt sådant som behöver kontext-switcha mellan adressrymder (göra OS-anrop som att kommunicera mellan processer).

Även med så pass "hemska" overhead-kostnader kommer de flesta applikationer påverkas så pass lite att det hamnar inom mätosäkerhet, upp till att se någon enstaka procent. Men finns alltid undantag och är trist om man råkar ha ett sådan som är kritiskt, därför viktigt att det finns en möjlighet att kunna välja att inte applicera fixen om man bedömer att förlusten av prestanda är värre än säkerhetsrisken (säkerhetsrisken kan vara noll i vissa fall, finns ju vissa förutsättningar för att dessa sårbarheter alls ska kunna användas).

Det kan finnas en långt enklare förklaring till varför just Skylake väldigt ofta finns med. Man måste komma ihåg att majoriteten av dessa svagheter tillhör Spectre-familjen och har ofta drabbat alla/nästan alla moderna OoO CPU-designer, oavsett tillverkare.

Skylake står ut rejält på två specifika punkter: ingen annan mikroarkitektur var "den senaste" under så lång tid (mid-2015 till mid-2019) som den. Det samtidigt som Intel fortfarande hade väl över 90 % av data-centermarknaden.

Det är nog väldigt naivt att tro att Raptor Cove och Zen4 skulle ha färre buggar än Skylake. Rimligen har de fler då antalet buggar tendera skala rätt väl med komplexitet, Raptor Cove och Zen4 är väsentligt mycket mer komplexa.

Både Zenbleed (endast Zen2) och den precis upptäckta DIV0 (påverkar bara Zen1) är ju betydligt simplare upptäcka/förstå jämfört med vilken som helst av Spectre-buggarna. Enda rimliga förklaringen att de inte upptäckts innan är att färre letat efter buggar på just de modellerna.

Inception-buggen är också interessant, som jag förstår det är den egentligen inte alls Zen-specifik (drabbar Zen1-Zen4). Den drabbar egentligen även visa Intel CPUer, men då denna sårbarhet i grunden är samma sak som Retbleed (som påverkade i stort sätt alla moderna high-end CPUer) finns redan fixar på plats. Skillnaden var att dessa fixar inte var tillräcklig på Zen med de förändringar man gjort från Retbleed.

Värt att notera är att det finns några moderna mikroarkitekturer som sticker ut i att de har rätt få sårbarheter. En är Gracemont, en annan som sticker ut rejält är Arm A5xx-serien.

Vad är speciellt med dessa? Med Gracemont, egentligen inget mer än att den är betydligt enklare än de snabbaste modellerna. Det är fortfarande en Out-of-Order design (så är påverkad av Spectre-varianter). A5xx är super-enkel, är den enda moderna relativt snabba CPU-design som inte är Out-of-Order (annars hittar man sådant mest i mikrokontrollers idag).

Som jag ser det måste man acceptera att den här typen av bugger kommer finnas i CPUer, vad är alternativet? Att droppa OoO-design skulle backa prestanda 20 år.

Accepterar man att den här typen av buggar är en del av livet kan man istället fokusera på det verkliga problemet: man måste klassificera data, "känslig data" (lösenord, etc) får helt enkelt hanteras av speciell HW som t.ex. CPU-kärnor som saknar OoO. Det skulle i majoriteten av fallen ha väldigt liten prestandapåverkan, skulle faktisk ha positiv prestandapåverkan då enda realistiska vägen framåt för högre prestanda är ännu mer spekulativa inslag i CPUer (majoriteten av dessa buggar kommer från spekulativ körning i CPUn).

Roligt att du kommer med bra information innan alla hinner klaga allt för mycket med sina killgissningar.

Om man gillar att lura sig själv så kanske man kan "förstå" det. Men det finns inget som säger att AMD inte också håller på med samma tricks. Men tror man på fullaste allvar att prestandaförlusten någon gång överstigit 35% så har man nog andra problem.