Allvarlig sårbarhet upptäckt i Apples systemkretsar

Anledningen att man måste ta till saker som Data Memory-Dependent Prefetchers (DMPs) är att utan dessa kommer djupare OoO inte hjälpa för det kommer inte finnas data tillräckligt snabbt för att utnyttja alla beräkningskapacitet back-end i CPUn har. Det är specifikt DMP som denna sårbarhet utnyttjar.

Intel är inte out-of-the-woods, det enda som konstaterats att metoden som fungerar på M1/M2/M3 fungerar inte på Raptor Cove. Man kan mycket väl hitta andra sätt, likt hur vissa SMT sårbarheter bara fungerar på Intels modeller medan andra bara fungerar på AMDs modeller.

Apples CPU är i nuläget den "bredaste" mikroarkitektur som existerar, enda som är i närheten är Arm Cortex X4 (och snart även Snapdragon X Elite). Utan "trick" som DMP och ett gäng andra skulle det vara helt omöjligt för en CPU att utföra ~50 % mer instruktioner per cykel jämfört med Intel/AMDs bästa (nu har även Raptor Cove DMP, så räcker inte enbart med detta men det en sak av många för att nå dit).

OoO är specifikt det som orsakar Spectre. Så vitt jag vet är alla OoO-designer drabbade av Spectre, medan de utan OoO-stöd inte är sårbara.

Säkerhet och CPU-prestanda står i allt mer kontrast till varandra. Men känns inte som ett omöjligt problem att lösa givet att det i praktiken är en rätt liten delmängd av vad program utför som spelar roll för säkerheten. Se bara till att göra dessa på beräkningsenheter optimerade för säkerhet, då går det att köra full-steam ahead för resten m.a.p. prestanda.

Skulle det hjälpa att tvinga att processera krypto-kod på de små kärnorna kanske? Eller sätta i separat kryptokärna med separat minne (det är väl i någon mening vad TPM är iofs)

Om Intel också har DMP varför har de inte lika bra prestanda per W som Apple?

Anledningen att man måste ta till saker som Data Memory-Dependent Prefetchers (DMPs) är att utan dessa kommer djupare OoO inte hjälpa för det kommer inte finnas data tillräckligt snabbt för att utnyttja alla beräkningskapacitet back-end i CPUn har. Det är specifikt DMP som denna sårbarhet utnyttjar.

Intel är inte out-of-the-woods, det enda som konstaterats att metoden som fungerar på M1/M2/M3 fungerar inte på Raptor Cove. Man kan mycket väl hitta andra sätt, likt hur vissa SMT sårbarheter bara fungerar på Intels modeller medan andra bara fungerar på AMDs modeller.

Apples CPU är i nuläget den "bredaste" mikroarkitektur som existerar, enda som är i närheten är Arm Cortex X4 (och snart även Snapdragon X Elite). Utan "trick" som DMP och ett gäng andra skulle det vara helt omöjligt för en CPU att utföra ~50 % mer instruktioner per cykel jämfört med Intel/AMDs bästa (nu har även Raptor Cove DMP, så räcker inte enbart med detta men det en sak av många för att nå dit).

OoO är specifikt det som orsakar Spectre. Så vitt jag vet är alla OoO-designer drabbade av Spectre, medan de utan OoO-stöd inte är sårbara.

Säkerhet och CPU-prestanda står i allt mer kontrast till varandra. Men känns inte som ett omöjligt problem att lösa givet att det i praktiken är en rätt liten delmängd av vad program utför som spelar roll för säkerheten. Se bara till att göra dessa på beräkningsenheter optimerade för säkerhet, då går det att köra full-steam ahead för resten m.a.p. prestanda.

DMPS tillsammans med OoO ger högre prestanda ja, men du kan skapa en OoO CPU helt utan spekulativ exekvering och du kan skapa en spekulativ CPU helt utan OoO.

OoO innebär enbart att CPU:n kan sortera om loads och stores utifrån vad som den ser som den bästa ordningen oavsett vad du som programmerare har skrivit i koden. Spekulativ exekvering är att CPU:n exekverar kod innan den vet om ifall den verkligen skall exekvera den koden eller ej.

T.ex så är och var ARM väldigt OoO medan x86 är och väldigt lite OoO (x86 är enbart OoO under väldigt specifika situationer vilket gör att många som skriver låsfria algoritmer under x86 plötsligt ser dem crash and burn på en ARM) men x86 är sedan en tid extremt spekulativ, främst vid branch-prediction eftersom branchning är så extremt kostsamt på en x86 då den har så djup pipeline.

OoO och spekulativ exekvering är två helt separata saker. Vad de är är två olika sätt att försöka hålla hela pipelinen upptagen med att exekvera data.

Du har helt rätt i att spekulativ körning och OoO är två ortogonala koncept.

Fattar inte denna sårbarhet tillräckligt i detalj, men i flera andra fall och specifikt i Spectre är både spekulativ körning och OoO ett krav för att trigga problemet.

Så egentligen ska man säga både OoO och spekulativ körning. Men i praktiken är OoO meningslöst utan spekulativ körning, så det senare är underförstått och många av de här buggarna kommer av kombinationen av dessa två.

Enda OoO CPU jag kunde hitta som inte också har spekulativ körning är den första CPU som använde Tomasulos algoritm på mitten av 1960-talet. OoO började användas först på 90-talet i någon större utsträckning, det efter att in-order designer redan börjat med spekulativ körning.

För in-order designer finns varianter både med och utan spekulativ körning. När Spectre presterandes var ett frågetecken huruvida Arms moderna in-order designer, som har spekulativ körning, var påverkade. De är inte påverkade, däremot är Arms OoO designer påverkade precis som alla moderna OoO designer (som alla också använder spekulativ körning).

Så åter igen: du har rätt att det är separata koncept, men i praktiken betyder "djupare OoO" också både mer och fler varianter av spekulativ körning. Utan det senare vore det helt hopplöst att utnyttja potentialen hos OoO, speciellt i en design som Apple Silicon som både är extremt "bred" och har ett enormt "out-of-order" fönster att utnyttja.

Edit: och bara för att understryka hur komplext det hela är om man försöker få med alla detaljer är detta ett bra exempel

"x86 är enbart OoO under väldigt specifika situationer vilket gör att många som skriver låsfria algoritmer under x86 plötsligt ser dem crash and burn på en ARM"

Detta har varken med spekulativ körning eller OoO att göra. Det har att göra med minneskonsistensmodell.

x86 implementerar en modell som kallas Total Store Order (TSO) medan Arm (likt de flesta RISC:ar, men inte alla, använder en betydligt mer "relaxed" modell).

Om tråd A skriver till minnescell A och sedan till B (i program order), det utan explicita barriärer, och en annan tråd sedan läser B och får det nya värdet garanterar TSO att om man då läser A från den tråden kommer man få det nya värdet. På Arm kan man även i det fallet potentiellt läsa det gamla värdet på A i frånvara av explicita barriärer.

Finns bibliotek som medvetet utnyttja TSO, inte helt oväntat finns prestandakritiska bibliotek från Intel som gör detta. Att korrekt översätta det till ARM64 blir inte effektivt om CPUn inte har möjlighet att aktivera TSO (vilket Apple Silicon verkar göra när den kör i kontext av Rosetta 2).

Mer vanligt är nog att det egentligen är race-condition buggar som råkar fungera alt. gör race-bugg:en tillräckligt osannolik när man kör på TSO. På en CPU med en mer relaxed konsistensmodell smäller det istället direkt...