Allvarligt säkerhetshål upptäckt i Intels processorer

Det där är ett GPU-test...

Man testar inte CPU:er och GPU:er på samma sätt.

AMD FTW, nästa uppgradering blir en AMD rigg som på den gamla goda tiden!

https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git/c...

AMD kämpar mot att deras CPUr skall patchas.
https://www.techpowerup.com/240187/amd-struggles-to-be-exclud...

Misstänker att Intel kämpar för att patchen skall gälla alla.

Tror du blandat ihop ett par distinkta koncept här. Går igenom den för man måste förstå lite av detta för att greppa vad denna bug har sina rötter i.

Front-line

Tar vi Apples A10/A11, Intels Core samt AMDs Zen har alla en front-end som hanterar instruktioner sekventiellt, d.v.s. detta steg är "in-order". Apples A10/A11 kan hantera hela sex (ARM) instruktioner per cykel, Zen kan hantera fyra x86 instruktioner och från Core2 till Broadwell hanterars fyra x86 medan Skylake hanterar fem x86 instruktioner. Alla dessa är "upp-till".

Dispatch
Nästa steg i processen är avkodning där instruktionerna bryts upp i interna "micro-ops", detta görs numera även på ARM. Dessa interna instruktioner är väldigt lika oavsett om det är x86, ARM eller något annat. I huvudsak delar man upp instruktioner i minnesoperationer, heltalsoperationer samt flyttalsoperationer. Här kan Apples A10 skicka iväg sex micro-op per cykel, AMDs Zen har också en kapacitet på sex micro-ops. För Core skiljer det igen mellan Core2-Broadwell som kan skicka iväg fyra micro-ops. För Skylake beror det vilka instruktioner det handlar om, är sex micro-ops vid träff i micro-op cache annars är det fem micro-ops. Alla dessa är som vanligt "upp till".

ROB
Sedan kommer ROB (ReOrder Buffer) in i matchen. Här är också där man går från in-order till att köra saker spekulativt, verkar vara just den spekulativa delen där buggen ligger i (återkommer till det). Storleken på ROB avgör hur många instruktioner som kan vara "in-flight", ju större ROB ju större chans är det att fullt ut kunna nyttja alla beräkningsenheter. ROB är 192 stor i Apples A10 (det taget från Apples LLVM beskrivning av A10, har ingen info för A11). Även Zen har en ROB på 192 platser.

För Core har ROB ändrats väldigt många gånger. Core2 (Conroe) har en ROB på 96, Nehalem/Westmere 128, Sandy/Ivy Bridge 168, Haswell/Broadwell 192 och Skylake har 224 platser i sin ROB.

ROB är en förutsättning för den s.k. Tomasulo tillståndsmaskinen som är metoden man använder för att köra saker "out-of-order" men ändå säkerställa att den externt observerade effekten är som-om man körde allt i sin korrekta sekvens.

Execute
När en instruktion som ligger i ROB har all indata kan den exekveras. Apples A10 kan påbörja upp till nio instruktioner per cykel (4 heltal, 2 minnesoperationer samt 3 flyttal/NEON). Inte helt säker på Zen här (hittar ingen info), men om det inte finns några begränsningar jag missat borde det vara upp till 12(!) instruktioner (som måste bestå av 4 heltal, 2 minnesoperationer samt 4 flyttal). För Core är det Haswell som är vattendelaren för ovanlighets skull. Innan Haswell är det max sex instruktioner (3 heltal/flyttal med valfri mix samt 3 minnesoperationer) medan Haswell och framåt är det åtta instruktioner (4 heltal/flyttal med valfri mix samt 4 minnesoperationer).

Retire
Sista steget är "retire". Tanken (och häri ligger buggen, tanken håller inte riktigt) är att "retire" steget säkerställer att den externt observerbara effekten blir som-om allt kördes in-order hela vägen. Apples A10/A11 kan "retire" 6 micro-ops per cykel, Zen 4 micro-ops per CPU-tråd (så totalt åtta per kärna). För Core är åter igen Skylake annorlunda, är 4 micro-ops (per kärna/tråd) fram till Broadwell medan det är 4 per tråd / 8 totalt per kärna i Skylake.

Lite OT men ändå väldigt intressant: sett över hela pipeline är Apples A10/A11 väsentligt bredare

Buggen
Måste säga direkt: vet inte exakt vad buggen är, den informationen är inte släppt än. Dock sa nog AMD-ingenjören lite mer än vad han egentligen fick i sin förklaring till varför Zen inte har problemet. Han nämnde spekulativ exekvering av kod som ligger på kärnans priviligeringsnivå (ring 0) när man fortfarande befinner sig i en applikation (ring 3). Detta gör det möjligt att göra en rätt kvalificerad gissning.

Hela poängen med ROB är att kunna köra saker i en annan ordning än den sekvens instruktioner faktiskt har. Vidare kan man "gömma" latens genom att "gissa", spekulativt, köra saker. Så länge man inte gör "retire" ändras inget av de tillstånd man normalt kan observera, är därför möjligt att spekulativ köra saker.

Den stora skillnaden mellan "big-core" designer som Core, Zen och Apples ARM och mindre kärnor är till stor del storlek på olika buffertar vilket bl.a. avgör hur mycket spekulativ exekvering som kan göras.

Vad Intel verkar göra och andra inte verkar göra är att spekulativt köra saker även om man spekulativt kör något som befinner sig på en högre priviligeringsnivå än vad man faktiskt befinner sig på.

Covert channel
Åter igen, jag gissar. Men är rätt 100 % säker på att buggen inte är att detta direkt låter "vanliga" applikationer läsa minne som tillhör kärnan. Men om nu spekulativ exekvering av kernel-kod händer när man fortfarande befinner sig i user-space kan det leda till indirekta effekter som kan observeras även om de inte går till "retire".

T.ex. så måste spekulativa läsningar/skrivningar läggas in i cachen. Man "ser" inte dessa innan de verkligen händer, d.v.s. "retire" körs, men bara det faktum att man slänger ut något som redan ligger där påverkar prestanda på ett sätt som kan mätas (kan blir cache-miss som inte skulle hända om den spekulativa koden inte gjorts)!

En sak man kan använda detta till är att få en bild av hur kärnans virtuella adressrymd ser ut. Om man får CPUn att spekulativt läsa en virtuell adress som inte är mappad i kärnan så kommer det inte påverka cache då en sådan access kommer generera ett undantag (ett page-fault som inte kan lösas då minnet faktiskt inte är mappat). Omvänt så kommer en virtuell adress som är mappad i MMU samt ligger i TLB (Translation Lookaside Buffer, cache för virtuellt-till-fysiskt minne) att i vissa fall orsaka en effekt som eventuellt kan observeras redan innan man når kärnan, operationen kanske inte ens händer i praktiken då effekten kommer av spekulativ exekvering.

Optimering
Hur har man då fixat detta problem? Fram till nu har både Windows och Linux (och tydligen även OSX, det var inte sant för 32-bit så måste ha ändrats för 64-bit) alltid en mappning för kärnans virtuella-till-fysiska minne. När man befinner sig i en applikation finns alltså den mappningen, men varje sådan mappning (varje "page") innehåller information om att man bara får läsa/skriva detta RAM om man befinner sig i ring 0.

Illusionen blir då att när man är i en applikation, ring 3, så är det som-om det överhuvudtaget inte finns en mappning för minnet som kärnan använder. Denna illusion faller då om min gissning ovan kring spekulativ exekvering är korrekt -> covert channel som kan utnyttjas till att minska / ta bort effekten av saker som ASLR (Address Space Layout Randomization, något som försvårar att nyttja buffert-overflow och liknande buggar).

Lösningen
Vad man gör för att lösa detta är att ta bort den permanenta mappningen av kärnans virtuella-till-fysisk-mappning. Man förlitar sig då inte längre på illusionen att minnet inte är mappat när man befinner sig i en applikation, kärnans minne är inte ens mappat rent fysiskt för applikationer.

Man hade redan en lösning för detta i Linux sedan något år tillbaka. Man har diskuterat om den alls behövdes innan denna bug, men rätt färdigdiskuterat nu antar jag...

Prestandapåverkan
Varför påverkar fixen prestanda och vad påverkas mest?

På x86 behöver man nu skriva till ett register med namn CR3 varje gång man hoppar mellan kärna/user-space. När man skriver till detta register byter man tabellerna som används för virtuell-till-fysisk minnesmappning. Och skrivning till CR3 flushar också TLB!!!

TLB är en otroligt prestandakritisk del, att göra en flush vid varje byte mellan ring-nivå kostar på.

Hur mycket beror helt på

• hur många minnesreferenser görs samt hur många "pages" (4kB per page i normalfallet) görs per switch

• hur ofta hoppar man mellan olika ring-nivåer

Saker som gör många små I/O-operationer kommer behöva hoppa mellan kärnan och applikationen ofta, därför påverkas t.ex. databaser och virtuella maskiner en hel del.

Spel påverkas inte då man av en rad skäl gör saker i batch, d.v.s relativt få switchar som var och en gör rätt mycket jobb -> kostnaden för TLB-flush amorteras över väldigt många operationer -> kostnad per operation är i det närmaste noll.

Att göra spekulativ exekvering i "fel" ring är något som absolut ger en fördel i IPC. Blir intressant att se om man lyckas hitta något som ger samma effekt utan att orsaka en covert-channel. Känns tyvärr rätt osannolikt

TL;DR buggen verkar vara att en tidigare framgångsrik illusion inte längre fungerar på Intels CPUer.