Tre svåråtgärdade sårbarheter kringgår Spectre-skydden

Snälla låt oss ha lätt användarvänlig åtkomst till att stänga AV dessa till synes onödiga "fixar" för vanliga datorer. Kiseljättarna bara gnuggar händerna och tackar för den nya formen av "unplanned obsolescence" samtidigt som problemen bara är något som serveradmins och dylikt måste ha i åtanke. Antingen det eller lagstifta att de måste dela ut nya processorer gratis.

Skulle hävda att den fetmarkering du gjorde hamnade fel, det viktigaste att ta med sig från den meningen är "information may be leaked across privilege levels", för det man menar här är att en process kan använda denna sårbarhet för att läcka information mellan user-space och kernel-space. När user-space kan läsa saker i kernel-space är det riktigt illa då kernel-space har access till i princip all information i systemet (d.v.s. information för alla processer).

Spectre är riktigt otrevlig då den drabbar alla moderna CPU-designer och den kostar prestanda att fixa, samt vissa varianter av Spectre verkat inte gå att fixa då det är allt för dyrt. Räddningen här har (så här långt) varit att det i praktiken är så komplicerat att använda Spectre då timing är superkritiskt, i många fall måste man skräddasy en attack för enskilda eller väldigt smala konfigurationer -> det skalar värdelöst så i praktiken finns långt bättre/enklare sätt att ta sig in i system -> "ingen" bryr sig om att använda Spectre.

Den trista med det man upptäckt här är att denna sårbarhet verkar vara mer lik Meltdown, en sårbarhet som turligt nog gick att patcha, vilket också krävdes i fall som molntjänster då det även i praktiken gick att utnyttja Meltdown där (lite på hemdatorer är nog även Meltdown lite som Spectre, finns långt enklare sätt där). D.v.s. likheten med Meltdown är att att det verkar vara enklare att faktiskt utnyttja denna sårbarhet, kombinerat med svårighet att matcha den lik Spectre...

I slutändan kan det är visa sig vara så pass komplicerat att utnyttja även denna att det inte blir något stort problem i praktiken, vi lär få se framöver. Då denna faktiskt kräver lokalaccess är det inte helt osannolikt att det inte blir så stort problem, för om någon som vill ta över din dator kommit så långt att de har lokalaccess finns det tyvärr en rad sätt att komma vidare, det även om just detta problem patchas. Tricket är helt enkelt att mota Olle i grind, de ska inte ens få någon form av lokal access.

Det jobbas på exakt den idén i Linux.

Problemet är att restriktionerna är större än vad man initialt kanske tänker sig...

Första problemet är relaterat till det jag svarade på ovan: det räcker inte att begränsa SMT så att båda trådarna hos en viss CPU-kärna alltid tillhör samma process, ska man vara riktigt säker går det bara att ha SMT aktiverat för processer man helt litar på förutsatt att SMT då också begränsas så att dessa betrodda processer allt kör båda trådar hos en viss kärna inom samma process.

Problemet med icke-betrodda processer är att det finns minst två priviligeringsnivåer. Dels när man kör i programmet, här vore det helt OK att låta vilken process som helst köra SMT då den bara kan "spionera" på sig själv (vilket är poänglöst). Men dels kör ju processer saker inuti OS-kärnan, en "elak" process kan då explicit använda SMT så ena tråden kör i kontext av OS-kärnan medan den andra utnyttjar sårbarheter som beskrivs i denna artikel för att gräva ut information som nu kommer från kärnan -> potentiellt kan man läsa information från alla processer om rätt/fel (beroende på ur vems perspektiv man ser det) "gadget" används av CPU-tråden som finns i OS-kärnan.

Svårt att se hur man någonsin kan göra SMT helt fritt från "side-channels" och det är redan bevisat att SMT "by-design" alltid lider av "covert-channels". Här kommer det ned till helt normala ingenjörsavvägningar: huruvida man ska behålla SMT på beror helt på vad som har störst värde, den extra prestandan SMT ger i många fall (vilket säger att det ska vara på) kontra de säkerhetshål tekniken har (vilket säger att det ska stängas av i alla lägen utom för "betrodda" processer + OS-stöd likt det Linux är på väg att få).

För de flesta hemanvändare lär den högre prestanda vägra tyngre, för molnleverantörerna kan mycket väl säkerheten väga tyngre.

Det är inte på Intels ansvar, det ligger på OS-tillverkarens ansvar då de flesta av fixarna implementeras där. I Linux finns standardmetoder för att stänga av enskilda/all patcher.

Finns även några som i praktiken appliceras av kompilator, finns ingen rimlig metod att stänga av dessa. Enda sättet vore att bygga två versioner av applikation, en med patch(arna) applicerade och en utan.

Men det är ju Microsofts operativsystem? Intel har försett alla förutsättningarna för att Microsoft ska kunna lägga till stöd att styra det, finns till och med exempel i viss grad iom Linux, det är däremot Microsofts jobb att få in det i deras produkt. Hade det varit OSS hade man kunnat motivera att Intel själva borde lägga in stödet, men Intel kan knappast begära källkoden till Windows för att få in deras ändringar. En av nackdelarna med stängd källkod, en ensam part som styr och det är helt efter deras vilja och tycke hur allt fungerar och vad man kan göra.

Detta är någonting som bör hanteras av operativsystemet och inte extern mjukvara då det handlar om operativsystemets mikrokod. (Mer exakt volatil inläsning av mikrokod till CPU'n av operativsystemet vid uppstart.)