Fix för AMD-sårbarhet påverkar knappt vardagsprestanda

Ouch! 54% i kodkompilering och databaser är en riktigt stor nackdel på business sidan som dessa processer är ämnade åt. Vi har äldre Threadripper processorer på jobbet för kompilering och en sådan minskning av prestandan skulle ha en klart menlig inverkan på användbarheten för min del. Dubblade kompileringstider kan betyda 5 minuter extra för att testa en mindre sak. Det blir mycket pengar för arbetstid i slutändan.

Sida 6, kompilering ca 10%. databaser blev dock ordentligt shaftade...

Gillar hur vinklade dessa nyheter om fixarna är, för Intel är det DOMEDAGEN 50% LÄGRE PRESTANDA *i vissa funktioner som inte påverkar vardagsprestanda överhuvudtaget

Medan för AMD, ja, detta.

Alltså, kodkompilering, databaser och bildbehanding är faktiskt vardagssysslor för många användare.

Det står väl ingenting om -54% för kodkompilering i Phoronix tester?! Ser bara resultatet för MariaDB på -54%

Alltid bra att läsa källan uppenbarligen! LLVM med Ninja är precis vad vi använder och det var ju knappt 2%. Ofantligt mycket bättre än jag trodde efter att ha läst bara SweC artikeln

Varför?

Kan inte avgöra om du är sarkastisk eller inte.

Håller med om att rubrikerna för denna och tidigare Intels Downfall-fix sänker prestandan rejält känns lite märkliga, verkligheten är väl ändå precis tvärtom dessa fall.

Benchmark vs mikro-benchmark

Phoronix test-suite är väldigt bra då den innehåller väldigt många tester, är helt fri att använda (och är öppen källkod) samt helt automatiserad.

Problemet med Phoronix test-suite är man måste vara ordentligt påläst för att överhuvudtaget fatta vad som faktiskt testas, har själv i praktiken noll koll på vad >50 % av sakerna de tester egentligen är ett test av. Positiva är att när något sticker ut är det ju bara ladda ner det hela och läsa på vad som faktiskt testas.

I fallet Downfall bör man notera vad som inte testas givet att det som sticker ut är saker som Ospray: Blender finns inte med trots att Ospray och Blender båda handlar om rendering. Orsaken är med väldig stor sannolikhet att prestanda i Blender knappt påverkas.

Fast hur är det möjligt att Ospray påverkas om Blender inte göra det, båda är 3D-rendering?

Ospray testerna som påverkas är uteslutande mikro-benchmarks, de testar ett väldigt specifikt moment i en större pipeline, de testar inte ett fullständigt flöde som att rendera en hel scen i Blender. För Downfall är det väldigt specifika moment som kan påverkas "upp till 50 %", men på ett helt flöde kanske detta moment står för <5 % totala beräkningstiden vilket gör att påverkan i "verkliga" fall ofta blir fraktioner av procentenheter.

Givet att AMD sa att de förväntade sig att fixarna för Inception inte skulle ge speciellt stor påverkan var jag övertygad om att samma sak gällde detta. Verkar ha haft fel om Inception...

Kritiskt vad och hur information kan läcka

Downfall (påverkar primärt CPU-modeller med AVX-512 stöd innan Alderlake), Zenbleed (påverkar bara Zen2) och DIV0 (påverkar bara Zen/Zen+) som alla presenterats rätt nyligen delar alla egenskapen att de "bara" kan läcka information från program som nyligen kört på samma fysiska CPU-kärna.

Alla dessa delar egenskapen att det är information i SSE/AVX register som kan läcka, men de kan inte läcka godtycklig information. D.v.s. helt klart ett hål, men rätt begränsat vad som är åtkomligt.

Delen jag helt missat i Inception är vad det som kallas "Phantom speculation" faktiskt går ut på. Phantom speculation, som är specifikt för hela Zen-serien, presterades tydligen redan förra året. Det fick nog inte så mycket uppmärksamhet i pressen då Phantom speculation i sig inte är tillräckligt för att orsaka data-läckage.

Men det visade sig kombon Phantom speculation och "Training in Transient Execution (TTE)" i praktiken är motsvarigheten till Meltdown på flera sätt!

Betydligt värre attack-vektor

Inception och Meltdown (som inte bara påverkade Intel utan även vissa POWER och någon enstaka Arm modell) är i grunden helt två separata klasser av sårbarheter, men de delar vad som kan läcka: vilket tyvärr innefattar innehållet i kernel-minne!!!!

De flesta av dessa CPU-sårbarheter är otroligt teoretiska attacker, de är mer att jämföra med "det är en förhöjd risk att ge sig ut i trafiken, men de flesta accepterar den risken då fördelarna överväger". Majoriteten av Spectre-attackerna verkar ens sakna fungerande proof-of-concept.

Inception delar tyvärr även Meltdown-egenskapen att det är, i sammanhanget, relativt enkelt att utnyttja buggen. Är inte fullt lika illa som Meltdown då det verkar ta längre tid att läcka via Inception, men då det som läcker innefattar kernel-minne finns inte alls något krav att köra på samma CPU-kärna som den man vill stjäla information från -> webbläsaren (JavaScript) blir en realistisk attack-vektor.

Alla out-of-order CPUer verkar mottagliga för TTE, det inkluderar Intels. Det är via TTE som data rent tekniskt läcker. Men utan "Phantom speculation" är man beroende av extremt specifika kod-sekvenser (s.k. "gadgets") för att kunna utnyttja detta, i praktiken är det ofta så att "rätt" gadget överhuvudtaget inte finns.

Det Phantom speculation gör är att man som "attacker" i praktiken kan skapa sina egna gadgets, vilket gör TTE användbar...

Givet att AMD känt till denna sedan minst i februari i år är det lite underligt att man inte har skydd mot alla CPU-modeller redan nu. För likt Meltdown är detta nog en sårbarhet man nog ska applicera motmedel mot på en datorn man surfar med.

Nu kanske ni just bygger LLVM med Ninja alt. bygger C++ projekt med Ninja som i kompileringskomplexitet matchar att bygga LLVM.

Detta är ännu ett exempel som visar hur svårt det är att dra rätt slutsats från Phoronix tester. Positiva här är att mixen av saker som Phoronix testar kring just kompileringar belyser väldigt väl när detta är ett problem!

Skillnaden mellan att bygga LLVM (C++ projekt där det tar relativt lång tid att bygga varje enskild fil -> primärt "compute bound") och bygga Linux-kärnan (C projekt där varje enskild fil byggs relativt snabbt -> betydligt mer "I/O bound") är att det senare fallet kommer ha långt högre frekvens av anrop mellan program och OS-kärna.

Fixarna för denna bug påverkar kostanden för att kontext-switcha, ju oftare det händer ju värre blir prestandaförlusten.

Trista är att "tunga C++" projekt är ett edge-case, inget annat är lika "tungt" att kompilera som detta och andra språk är mer likt Linux-kernel fallet (fast få projekt är i närheten lika stora, så ur den aspekten påverkas man ändå inte lika mycket).

Superpositiva för er lär vara att ni antagligen inte använder er TR på ett sätt så okända kan köra saker på den (lär t.ex. inte vara någon som sitter och surfar på den datorn eller använder den som datacenter där okända kör sina program), i det läget är det ju helt OK att skippa fixarna för det är i praktiken rätt hopplöst att utnyttja sårbarheten.

Phoronix gjorde sina tester med en Zen3 CPU, det är modellen som påverkas klart minst. En "äldre TR" kanske betyder Zen2 eller Zen1, de är långt mer påverkade om man ska tro det forskarna listar i sin rapport. Även Zen4 har ju mer än dubbelt så stor "overhead".

Overhead är inte ett mått på direkta prestandaförsämringen, ökar overhead med x2 minskar inte prestandan till hälften utan påverkan är i praktiken betydligt mindre.

100 % overhead betyder att just det som påverkas blir hälften så snabbt, men det är sedan en liten del av ett större flöde. Tyvärr blir denna del overhead:en påverkar en relativt stor andel av flöden med väldigt mycket kontext-switchar (vilket bl.a. påverkar I/O-intensiva fall som kompilering och än mer databaser)

Det märkliga är dock att totala prestandaförsämringen som Phoronix fått är i vissa fall större än den "overhead" forskar listar... Undrar vad det kommer sig av?

Du tänker på Cavium/Marwell Thunder X2, det är en out-of-order ARM64 med 4 trådar per CPU-kärna.

Ser inte varför det skulle vara någon skillnad om man har 2, 4 eller 8 trådar (vissa IBM POWER har 8 trådar, finns även någon SPARC men den var in-order så inte påverkad).

Likt Intel och POWER så har Thunder X2 en "unified scheduler", vilket gör att den klarar sig undan SQUIP.

Zen, "Apple Silicon" och numera även Intel E-cores har alla distributed schedulers, men de två senare klara sig från SQUIP (som likt Spectre är en familj av relaterade sårbarheter) då de saknar SMT. Å andra sidan klarade sig Zen från ett par SMT hål som drabbade de andra just p.g.a. sin distribuerade schemaläggare.

Detta är en rejäl "whack-a-mole". Initialt såg det ju ut som AMD gjorde ett genidrag med både distribuerad schemaläggare och att man har mer statisk uppdelning av resurser mellan SMT-trådar jämfört med t.ex. Intel. Detta gjorde att Zen undvek flera sårbarheter.

Nu när EPYC blivit vanligt har intresset ökat, bl.a. för den typ av sårbarheter som Inception har forskarna nu kommit på sätt att förstärka sårbarheter just p.g.a. av den mer statiska uppdelningen av resurser (Intel "klarar" sig lite här p.g.a. att de uppför sig annorlunda på den punkten).

Så ingen design verkar varit "säkrare", man behöver bara lite olika strategier för att attackera respektive design

Tillbaka till Thunder X2 tror inte jag den generellt har färre problem av en enda anledning: likt de flesta Arm-designer är den enklare än prestandamässigt motsvarande x86_64 designer. Mindre komplexitet lär ge färre buggar.

De SMT-specifika buggar bygger på att mer än en tråd delar samma fysiska kärna, kvittar hur många trådar som delar det hela. Vissa SMT-specifika attacker kan faktiskt bli svårare (men inte omöjligt) att göra med >2 trådar då den som attackerar inte vet vilken av de andra trådarna som gör en viss sak. Det gemensamma dessa har är: slår man av SMT "löser" man problemet. En annan lösning som används i t.ex. molntjänster är att en viss användare alltid kör på alla trådar på varje fysisk kärna (så fungerar i praktiken AWS, Azure, Google Cloud, m.fl).

Meltdown var ett resultat av "för mycket kreativitet", man gjorde saker som definitivt var positivt för prestanda men det bröt isoleringen mellan user-space / kernel. Intel var dock långt ifrån ensam om att göra detta fel, finns både 32-bit Arm, ARM64 och POWER designer som gjorde samma miss...

Inception bygger på bl.a. Phantom speculation. Phantom speculation är igen ett resultat av "för mycket kreativitet", Zen får delvis sin prestanda från att den spekulerar kring var hoppinstruktioner bör finnas i instruktionströmmen innan man ens avkodat instruktionen(!!!).

Det är definitivt positivt för prestanda då man väldigt ofta spekulerar rätt, men då man faktiskt inte har någon möjlighet att veta vad som egentligen ligger där blir det svårt skydda sig mot "påhittade sannolika punkter med hopp" (är det som är phantom speculation).

Just det senare är långt osannolikare bug på de ARM64 designer som finns då sådana "trick" ger mer prestanda ju högre man försöker klocka en design. Thunder X2 låg på runt 2,5 GHz, är väl Apple som idag klockar högst och de maxar på 3,7 GHz i nuläget (+ att de saknar SMT).

Skrivit det flera gånger tidigare: jag tror att den vettiga vägen framåt är att förlägga "säkerhetskritiska" saker till speciella in-order CPU-kärnor (med eget minne!). Sedan har man "racing-kärnor" i samma CPU som prioriterar prestanda, är helt enkelt för mycket man har att vinna på att spekulera "hejvilt" samtidigt som det kommer orsaka säkerhetshål.

Delen man först måste kika på är om det är realistisk att programmera en sådan design, men tror det kan fungera med rätt programvarustöd (likt hur Nvidia blivit så framgångsrik med GPGPU, det är väldigt komplicerat att använda utan "rätt" programvarustöd).