AMD: "Spectre kommer kräva uppdateringar av mikrokoden"

Man får väl även hoppas då att Mikrokoduppdateringen för med sig lite annat godis också. Annars brukar ju folk inte vara så sugna på att uppdatera när systemet i övrigt fungerar bra.

Skönt också att åter få bekräftat att AMD's processorer är immuna mot Meltdown, som ju är den allvarligare av sårbarheterna.

Åh nej inte mikrokoden... Den sitter väl i modermodemet? Inte lätt att komma åt.

Nej, inte nödvändigtvis. Mikrokoden kan laddas av OS-kärnan vid boot också.

Det förklaras lite dåligt vad microkoden innebär för något. Är det ett mjukvarufel eller ett hårdvarufel? Dvs. befintliga processorer kommer inte kunna bli immuna/åtgärdas?

"Konkret hoppas AMD kunna åtgärda Spectre variant 1 med en operativsystemsuppdatering, medan variant 2 kommer kräva en uppdatering av processorernas mikrokod."

Mikrokod är mjukvara och befintliga processorer kan enkelt uppgraderas. AMD och Intel tillhandahåller mikrokoden som krypterade binära blobbar som BIOS/UEFI och/eller operativsystemet kan byta ut mot en nyare version. För Linux är det bara att installera paketet amd64-microcode (eller motsvarande) när det kommer en ny version av paketet, eller så väntar du på en BIOS-uppdatering som innehåller den nya mikrokoden från din moderkortstillverkare. Antar att Windows-kärnan injecerar mikrokod på liknande sätt som Linux och då kommer fixen som en vanlig operativsystemsuppdatering.

Det är ett mjukvarufel i hårdvaran

I moderna processorer är processorns instruktioner oftast implementerade via mikrokod, istället för att vara implementerade direkt i hårdvara. D.v.s. varje instruktion består av ett litet mikroprogram som talar om för processorn vad den ska göra. Det gör att man kan ändra processorns beteende utan att behöva ändra på hårdvaran, t.ex. för att fixa buggar. Se Wikipedia för en mer ingående beskrivning.

Det är sant, men å andra sidan handlar det som tur är bara om mikrokod. Det hadde varit värre om det var mycket kod.

Vilka?

AMD har inte sagt att deras processorer är immuna. Det har väl snarare varit allmänt känt att Spectre även sannolikt kommer att påverka processorer från AMD också.

Den är ju så jävla liten också. Aspilligt.

Mikrokod kan användas på flera olika sätt, vanligast är att man använder det till att rätta buggar i hur existerande instruktioner används.

I fallet Spectre Variant 2 gör man något som är lite spännande ändå, man lägger till helt nya instruktioner till instruktionsuppsättningen! I detta fall handlar det om instruktioner som påverkar spekulation av hoppinstruktioner.

Spectre Variant 2 verkar seglat upp som den mest problematiska delen i denna soppa.

Variant 3 må ha en värre effekt (man kan indirekt läsa kärnans minne), men där finns en fix som är 100 %-ig sett till säkerhet + att den helt kan implementeras av OS (lätt att rulla ut).

Variant 1 är den som nog var värst för "vanliga" användare då den största attackvektorn var JavaScript i webbläsare. Här verkar det ändå se ut som fixarna inte har någon större prestandapåverkan.

Variant 2 må vara den som nog är svårast att skapa fungerande attacker med. Men tyvärr är det inte omöjligt och mycket pekar på att prestandapåverkan på fixarna i vissa fall är helt i nivå med Meltdown (det innan Meltdown-fixarna fått sina optimeringar, från Haswell och framåt finns HW-stöd som klart minskar effekten av Meltdown-fixarna).

Spectre-buggarna är problematiska sett till utrullning, krävs fixar både i applikationer, OS och för Variant 2 även i mikrokod.

De sa aldrig att de var immuna, utan att det fanns en "near zero" risk att någon skulle kunna utnyttja säkerhetsbristen Spectre på AMD-processorer och ingen har hittills lyckas demonstrera en fungerande exploit för Spectre på AMD i praktiken. Detta stämmer fortfarande, men med denna uppdatering går det nu från "near zero" till "zero" d.v.s. till och med det teoretiska säkerhetshålet täpps till

När det gäller Meltdown är AMD fortfarande helt immuna.

Fast det handlar inte om en teoretisk risk, det handlade främst om att AMD vägrade ge forskarna tillgång till detaljerna för deras BTB (Branch Target Buffer). Forskarna själva ansåg därför att det bara handlade om att de ännu inte lyckats göra reverse engineering på BTB, man har nu i alla fall kommit så långt i det arbetet att man helt förstår varför de proof-of-concepts som gjorts för Haswell inte fungerar på Zen.

En annan detalj som kommit fram är att det finns chans/risk att en fungerande attack-kod för Zen även kommer fungera på Samsungs M1, M2 och M3 ARM-CPUer (används som "big-core" i senare Exynos-kretsar) då de använder samma algoritm.

Spectre Variant 2 är den klart svåraste sårbarheten att utnyttja, den är tyvärr också den svåraste att laga 100 %-igt + den verkar tyvärr även ha rätt kraftig prestandapåverkan i vissa fall. Här får man hålla tummarna att det blir samma utveckling som Variant 1 där den initiala idén för en fix hade rätt stor prestandapåverkan men där man nu hittat andra betydligt bättre sätt att lösa problemet.

?

Intel gick ut dag 1 (eller heter det dag 0 på "säkerhetsspråk" kanske?) med att man kommer skicka ut uppdatering till mikrokod. Denna mikrokod levererades till OEM:er i samband med uttalandet.

Man har även skrivit ett whitepaper. I kapitel 3.2 går man igenom varför det behövs en mikrokoduppdatering

"The first technique introduces a new interface between the processor and system software. This interface provides mechanisms that allow system software to prevent an attacker from controlling the victim’s indirect branch predictions, such as flushing the indirect branch predictors at the appropriate time to mitigate such attacks."

Detta "new interface" är i Intels fall tre nya instruktioner som numera även fått namn

• IBRS - "indirect branch restricted speculation", ser till att separera BTB-poster som skapas av kärnan inte kan detekteras av user-space (user-space = miljön "vanliga" applikationer körs i)

• STIBP - "single thread indirect branch predictors", ser till att BTB-poster som skapas av en CPU-tråd inte kan användas för att "attackera" en annan tråd som kör på samma fysiska kärna (d.v.s. detta är bara relevant på modeller med SMT/HyperThreading)

• IBPB - "indirect branch prediction barrier", gör det möjligt att rensa innehållet i BTB när man byter mellan applikationer så man inte kan "träna" BTB i applikation för att sedan attackera en annan efter en kontext-switch

Nu blandar du in en annan sak som inte riktigt har med saken att göra.

x86 instruktioner avkodas av en dekoder, varav de flesta Intel-baserade har fyra (fast Skylake har fem). Varje x86-instruktion kan omvandlas till en, två, tre eller fyra så kallade micro-ops, vilket sedan är vad som exekveras. Vill man tala nittiotals-språk, så är x86-instruktionerna CISC och micro-ops RISC, men det där är ett lite farligt sätt att uttrycka sig på eftersom ingen riktigt definierat vad RISC är.

Ibland stöter man på en x86-instruktion som kräver fler än fyra micro-ops för att beskriva. Då kan den inte hanteras av de vanliga dekodrarna, utan skickas iväg till en speciell enhet som genererar så kallad mikrokod för det. Detta är långsamt och bör om möjligt undvikas, och är något Intel gör för instruktioner som de inte vill att någon skall använda längre, men som ändå måste fungera.

Detta har ingenting med det här problemet att göra.

Intel kan också styra hur visa av deras inbyggda enheter fungerar genom att programmera om dem. Detta kallas tyvärr också för mikrokod, men det är alltså inte samma sak. I 99% av fallen är detta bara att stänga av funktioner som inte fungerar, men ibland kan de istället lägga till funktioner - som här.

Intel programmerar om branch predictorn så att den är försiktigare med vilken information den använder för att förutsäga en branch.

Det är värt att påpeka att Intel inte direkt bidrog med information om hur deras branch predictor fungerade heller. Forskarna lyckades lista ut det för Intel, och kommer säkert att lyckas för AMD också.

IBPB är en enkel instruktion - den används för att rensa branch predictorn manuellt. De andra två är exekveringslägen, om vi uttrycker oss på det viset. Om man slår på IBRS så kommer branch predictorn i kernel-läge inte att använda information som den lärt sig när den är i user mode. Jag vet inte om det var det du menade, men det ser ut som om du skrev tvärtom nu? Detta läge kostar uppenbarligen en hel del prestanda.