Linus Torvalds kritiserar Intels hantering av Meltdown och Spectre

Linus försöker förklara varför han ofta är så oartig.
Hellre tydlig och oartig än otydlig och artig.

Varför måste man vara antingen eller; Kan man inte vara tydlig och artig?

Kan du peka på var man lyckats utnyttja Meltdown via JavaScript? Givet det jag vet krävs ett programmeringsspråk som tillåter "osäker" pekararitmetik, vilket utesluter attacker från en rad populära språk som t.ex. JavaScript, Python men även Java och C#.

Meltdown är absolut det som är den värsta bristen givet att den är relativt enkelt att utnyttja och effekten är att man kan läsa OS-kärnans minne. Det "trevliga" är att ingen så här långt hittat några "remote exploits" samt att det är tekniskt enkelt att patcha.

Spectre Variant 1 är det som man visat proof-of-concept attacker via JavaScript i webbläsaren. Det "positiva" här är att patchen för detta kostar rätt lite prestanda. För just webbläsare har man redan börjat rulla ut fixar. Det negativa är att "patchen" kräver analys av koden och manuell modifiering av alla funktioner som är utformade så de kan vara påverkade av Variant 1. Som tur är kan man hitta de flesta sådana fall med s.k. statisk kodanalys (finns bl.a. plugins till Coverity), men det kan ge en viss mängd både "false-positives" och missade faktiska fall.

Det Torvalds et.al. nu har meningsskiljaktigheter kring är hanteringen av Spectre Variant 2. Denna är som tur är svårast att utnyttja, men finns fungerande proof-of-concept.

Det som ställer till det här är att prestandapåverkan från patchar för Spectre Variant 2 får i många fall Meltdown-fixarna att blekna i jämförelse, det finns fall med enorm prestandapåverkan. Inte kul för något som påverkar precis alla CPU-modeller med "out-of-order execution" (vilket är alla moderna CPUer förutom de riktigt billiga som t.ex. Cortex A53).

För just Spectre Variant 2 vill jag personligen absolut ha kvar möjligheten att själv välja vilka system som ska skyddas och även vilka specifika program på ett visst system som ska skyddas. Program som hanterar lösenord och liknande måste ju skyddas, men ser t.ex. noll anledning att patcha saker som kompilatorer, program som utför beräkningar som "vanlig användare" etc.

Spectre Variant 2 är också väldig komplex i det att ingen av Intel/AMD lär vilja ha kvar det API som de skapat (ja, de har enats om att ha samma HW-gränssnitt på x86 CPUer för detta). Det är gissningsvis orsaken till varför APIet är "designat av idioter" och finns säkert saker att putsa på men man lär nog vilja undvika att designa detta som man normalt designar har/har inte finesser i x86.

Vissa program kommer kompileras om med "retrampoline", för dessa program vill man ju helst undvika mikrokod-patcharna då retrampoline kostar väsentligt mycket mindre. Retrampoline dock inte gratis, ger i runda slängar en x10 ökning av kostnaden för att returnera från en indirekt hopp (sett siffror som säger 3-4 cykler till ~30 cykler). Mindre problem för Linux-kärnan då den inte har någon enorm andel av indirekta hopp, betydligt större problem för program skrivna i "objekt orienterade språk" (språk är inte OO, designen är OO och språk kan har mer eller mindre syntaktiskt socker för att underlätta OOD).

Men vissa program kommer av olika skäl inte kompileras om, för dessa har man då bara valen att acceptera att de är mottagliga för Variant 2 alt. så kan man patcha dem m.h.a. mikrokod + OS-stöd (betydligt större prestandapåverkan än "retrampoline", prestanda kostnaden varierar tydligen också mellan CPU-modeller).

Det luriga här är att i framtiden när vi får CPU-modeller som inte är påverkade av Spectre Variant 2 vill man ju knappast ha kvar saker som "retrampoline" och än mindre branch-target-barriärer (det som lags till med mikrokod nu). Kommer inte bli kul att hantera detta framöver, ska man bygga två binärer och välja vilken som ska köras baserad på CPU-modell (teknisk fullt möjligt, Apple använde detta under PPC/x86 övergången), ska man acceptera kostnaden för workaround eller deklarerar man bara i något läge att de som bryr sig får uppgradera till en ny CPU (gissar att detta kommer bli fallet i praktiken).

Alla andra CPU-tillverkare har "klarat" sig rätt mycket från rampljuset då Intel fått stå där i egenskap av att de har överläget störst marknadsandel i datacenter.

Apple har sagt att man är mottaglig, dock patchade iOS redan i november/december. Givet vad man typiskt använder iOS-enheter till tvivlar jag att fixarna för Meltdown har någon märkbar effekt överhuvudtaget, skulle de mot förmodan ha det får Apple kanske lite nytta av sin runt dubbla enkeltrådprestanda mot Samsungs/Qualcomms ARM SoCer.

Ser även ut som IBMs POWER7+, POWER8 och POWER9 är påverkade av alla tre varianter. IBM lindar in det hela väldigt mycket, så svårt att säga med 100 % säkerhet. Dock nämner man alla tre CVEIDs på denna sida.

Så verkar mer att AMDs Zen är undantaget än regeln att klara sig från Meltdown när man tittar på de absolut best presterande CPU-kretsarna.

Vad det gäller Spectre Variant 2 är ARM-storyn rätt mycket luddigare än x86. Vad jag läst mellan rader är att ARM har redan standardfunktioner för att kunna hantera Variant 2 till 100 % eller väldigt nära 100 % (kräver dock ändå uppdateringar till OS och programvara). Om det stämmer ser det väsentligt trevligare ut för ARM-lägret än för x86-lägret, Spectre Variant 2 är en total clusterfuck på x86.

Tänkte uttalat mig för ett bra tag sen efter att Spectre/Meltdown uppdagades att det bara är början av en enorm skandal. Det kommer på sikt ha enorma ekonomiska konsekvenser för Intel i form av stämningar som kommer att hagla in (gör redan) samt alla minst sagt upprörda storföretags/datacenterkunder som kommer sniffa sig till Epyc gen2 som nygrillad oxfilé.