Kritisk sårbarhet i Intel-processorer funnen

Man måste ju inte uppdatera bios?

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

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

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.

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

Intressant att sårbarheten upptäcktes för ett år sedan, vilket inte helt framgår utifrån artikeln.

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

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

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.