Google och Microsoft upptäcker nytt säkerhetshål i processorer

Trädvy Permalänk
Datavetare
Plats
Stockholm
Registrerad
Jun 2011

Ovan skrivet: självklart ska vi kräva att detta fixas i kisel.

Och lyfter man blicken inser man rätt snabbat att det inte är spekuleringen som är grundproblemet, spekulering är ett stenhårt krav för att inte backa 20 år i CPU-prestanda.

Problemet är att man i vissa fall kan detektera spår av misslyckad spekulering genom att studera sekundära effekter i CPU-cachen.

Lösningen blir då relativt uppenbar: det måste till en L0$ som är helt osynligt för "vanlig" program. Alla spekulativa minnesoperationer får endast använda sig av denna L0$ (som av praktiska skäl kommer bli väldigt liten då den måste vara väldigt snabb).

De mest avancerade CPUer kan hålla 200-300 instruktioner "in-flight", på en x86 är i runda slängar 1/3 av dessa minnesoperationer (normalt något lägre på RISC:ar). Av dessa är det bara de som utförs spekulativt som måste använda L0$.

Så en lösning för ALLA de svagheter vi sett så här långt är att kasta lite mer kisel på problemet för att ta bort möjligheten att i efterhand kunna mäta effekten av misslyckad spekulation. Gissar att det är något sådant vi kommer se.

Nästa Xeon-version, Cascade Lake, blir nog först ut med HW-skydd och den borde ju komma under sommaren. Man får se då om det framkommer hur de löst detta.

Edit: att kalla det för "cache" blev lite fel, vad som måste läggas till är ett buffertutrymme logiskt innanför L1$ där alla spekulativa minnesoperationer endast finns till dessa att man vet att spekulationen är korrekt.

Till skillnad från en traditionell cache så skulle denna L0$ vara helt temporär, d.v.s. så fort man vet att spekulationen är fel/rätt så tas informationen bort (är den fel kastas den, är den rätt läggs den i "vanliga" cachen).

Intel borde vara rätt nära detta redan tack vare TSX. Är rätt mycket så "lock elision" är implementerat, fast TSX använder L1D$ för att hantera transaktionen. Ny kretsarna måste offra mer kisel på en buffert/data-cache som är helt dedicerad till att göra alla spekulativa minnesaccesser helt osynliga i den "vanliga" cachen.

Care About Your Craft: Why spend your life developing software unless you care about doing it well? - The Pragmatic Programmer

Trädvy Permalänk
Hjälpsam
Plats
Karlskoga
Registrerad
Jan 2007

Till saken hör väl också att Spectre verkar kräva väldigt mycket CPU-tid, för att kunna vaska fram någonting.
Om du är ute efter elakheter, är det troligtvis bättre att använda den CPU-tiden till något annat hyss

AMD Ryzen 7 1700 | Vega RX 64 | https://valid.x86.fr/ufsz9j | Stockkylaren | Bitfenix Whisper M 750W | Corsair 600T Graphite vit.
AMD FX8350 | Polaris RX 460 4 GB | https://valid.x86.fr/0q5pkm | Cooler Master V 700W | 32 GB ECC-Minnen.
HTPC | https://valid.x86.fr/ez1zxw |

Trädvy Permalänk
Medlem
Registrerad
Aug 2012

Se om min 8700k duger att ha i htpcn sen när allt är tilltäppt 😋😉

Vad går dessa cpuer som begagnade nu med alla säkerhetsbrister?
1000-1500kr

i5 8400 All cores clocked to 4015MHz
R5 1600X @ 4.3GHz https://valid.x86.fr/g5aaif

Trädvy Permalänk
Medlem
Plats
Luleå
Registrerad
Jan 2009
Skrivet av Decimal:

Se om min 8700k duger att ha i htpcn sen när allt är tilltäppt 😋😉

Vad går dessa cpuer som begagnade nu med alla säkerhetsbrister?
1000-1500kr

Kanske skulle skippa allt som har med elektronik att göra då? ingenting är helt säkert, att du skulle bli "hackad" med hjälp av dessa säkerhetshål känns så långt ifrån troligt att du antagligen har betydligt större problem i ditt liv än CPUn i din HTPC.

Trädvy Permalänk
Medlem
Registrerad
Aug 2012
Skrivet av Viochee:

Kanske skulle skippa allt som har med elektronik att göra då? ingenting är helt säkert, att du skulle bli "hackad" med hjälp av dessa säkerhetshål känns så långt ifrån troligt att du antagligen har betydligt större problem i ditt liv än CPUn i din HTPC.

Jag va mest ironisk 😊🤗

i5 8400 All cores clocked to 4015MHz
R5 1600X @ 4.3GHz https://valid.x86.fr/g5aaif

Trädvy Permalänk
Medlem
Plats
gbg
Registrerad
Nov 2007
Skrivet av Yoshman:

Är ett väldigt rationellt beslut i detta fall. Tack och lov att det finns någon gräns för hur mycket man dansar efter säkerhetsprimadonnornas pipa...

På vilken grund hävdar jag då detta?

För att det ens ska vara teoretiskt möjligt att utnyttja denna sårbarhet måste fyra saker vara uppfyllda

  • det kontext, A, som ska stjäla information måste vara separerad från det kontext, B, informationen ska stjälas från på ett sätt så det normalt inte ska vara möjligt för A att läsa minnet hos B

  • en läsning, L, måste följa en skrivning, S, där de två minnesoperationerna använder olika register att referera in i minne, vid körning måste de två minnesoperationerna referera samma adress eller åt i alla fall delvis överlappa

  • beräkningen av adressen för S måste bli fördröjd, t.ex. cache-miss eller liknande, medan beräkningen av adressen för L är direkt tillgänglig (vilket åter igen kräver att adresserna ligger i olika register, är det samma register drabbas ju båda lika)

  • det data som L erhåller måste användas till en påföljande minnesoperation, exakt var i cachen denna operation hamnar är det som ger den möjliga sidokanalen (vilket då implicit betyder att den som attackerar måste ha viss styrning över vilken adress L sker)

Hur vanligt är detta då att allt ovan är uppfyllt i verklig kod?

Microsoft har tittat på en hel i deras egna system och har så här långt hitta noll sådana fall. D.v.s. så vitt de vet är det inte ens teoretiskt möjligt att utnyttja svagheten i praktiken. Två stora orsaker här, dels är det rätt strikta krav och dels försöker kompilatorer (och programmerare som har någon känsla för att skriva effektiv kod) i det längsta undvika implicit aliasing av minnesaccesser. Kompilatorer kommer inte heller generera load/stores med olika register för minnesreferens när det är uppenbart att operationerna läser samma minne (eller samma baspekare med lite olika offset, men i det läget "ser" CPUn om det blir en RAW och undviker då att spekulera).

Faktum är att så här långt har man sett exakt noll försök till att utnyttja någon av de fyra svagheter som presenteras så här långt. OBS: man har alltså inte ens sett försök till att utnyttja dessa svagheter. Normalt ser man massor med försök att utnyttja svagheter, men många attacker stoppas i praktiken av olika skyddsnät (antivirus och liknande).

Varför?

Tja, vad är kraven på de övriga

  • speculative execution bounds-check bypass: "Spectre variant 1", denna hade antagligen utnyttjas om inte webbläsarna patchas så snabbt. Av alla svagheter är detta den enda där det är sannolikt att en vanlig konsumentdator skulle attackeras, så självklart ska denna patchas (är som tur är relativt billigt prestandamässigt, tyvärr måste man patcha varje sårbar programvara då det inte går att föra en CPU-fix)

  • branch target injection: "Spectre variant 2", detta påminner rätt mycket om det som nu upptäckts i att kravlistan på saker som måste vara uppfylld innan denna ens är teoretiskt möjligt att utnyttja är lång. Här krävs i praktiken till och med att man redan fått virus/malware på en normal desktop-maskin då saker som JavaScript-motorer hindrar attacken. Fixen för denna ger relativt stor prestandapåverkan i vissa fall, är också fixarna för denna som orsakat en rad stabilitetsproblem på Windows..

  • rogue data cache load: "Meltdown", är fullt möjligt att utnyttja denna i praktiken på en server där flera virtuella instanser kör och där de som administrerar respektive virtuell instans inte litar på varandra (så där måste man självklart patcha!!!). Är i praktiken i det närmaste ofarlig på en typisk desktop-dator, precis som "Spectre variant 2" krävs att den som attackerar först får in virus på din dator innan det ens är teoretiskt möjligt att nyttja svagheten.

Argumentet har varit att spectre variant 2 och meltdown ändå är relevanta på desktop då de i teorin ger en attackvektor för ett virus (som redan måste finnas lokalt på systemet!) att bli root/admin. Helt sant, men det är långt ifrån enkelt att lyckas med det i praktiken och under 2017 upptäcktes i genomsnitt två "local privilege escalation" per vecka i Windows. Är väsentligt enklare att utnyttja dessa jämfört med att försöka med spectre variant 2 / meltdown.

Bilden över hur lätta dessa svagheter är att utnyttja är nog rejält felaktig. I praktiken är det svårt att utnyttja de flesta av dessa svagheter ens i proof-of-concept där man totalt kontrollerar både programvaran som ska attackeras (den är i PoC helt tillrättalagd) och programvaran som utför attacken. Både i variant 2 och 4 måste man matcha dessa två programvaror helt för det specifika fallet (d.v.s. HW-konfig, OS, etc.). Variant 2 visat sig vara extremt svårt att utnyttja ens i PoC.

Säkerhet är absolut viktigt, försöker absolut inte hävda att man ska skita i det (skulle aldrig köra viktiga saker i "molnet" på en server som inte är säkrad mot meltdown). Men får finnas någon balans mellan risk och tillfört värde.

Rätt många åkte nog bil till jobbet i morse. Det trots att lite fler än två människor dör p.g.a. trafikolyckor per minut. Värdet att utsätta sig för den risken överväger för de flesta vida risken att förolyckas. För datorer är det egentligen ännu lättare att bedöma risk/värde: så länge jag vinner mer på att ta en risk jämfört med genomsnittskostnaden för problemen är det rationellt att ta risken!

Jag sågar inte din förklaring, men jag motsätter mig Intels sätt att resonera när man skickar ut patchar som i grundläget, av citatet att döma, inte åtgärdar det som man i så fall skulle ha i syfte att åtgärda genom att applicera själva patchen på ett system.

Man får ju anta att de ser det som ett potentiellt säkerhetshot då de bemödat sig att utfärda en patch mot det, eller hur?

Hade hellre sett att valet stod mellan att applicera patchen på systemet eller inte, dvs. om man applicerar patchen är standardläge skyddad+prestandaförlust vs. oskyddad, utan prestandaförlust.

Gillar verkligen inte trenden mot att patchar som förebygger potentiella -men svårutnyttjade- säkerhetshot skall behöva någon slags manuell handpåläggning och aktiveras likt en "feature".
Även om man inte påträffat saker i det vilda ännu lär det finnas stater och företag som jobbar dagarna i ända med att finna sårbarheter och sätt att utnyttja dessa, dem lär inte vara de första som informerar tillverkarna om ev. brister de upptäcker.

Tower: ace Battle IV | CPU AMD Phenom II X2 BE unlocked 4cores@3,2GHz | RAM 8GB DDR2@800MHz | MB ASUS M4A785-M | GFK AMD Radeon HD 6850 1GB | HDD Kingston SSD Now 60GB (/) Seagate 2TB(/home) | OS Ubuntu 16.04 LTS

Trädvy Permalänk
Datavetare
Plats
Stockholm
Registrerad
Jun 2011
Skrivet av krigelkorren:

Jag sågar inte din förklaring, men jag motsätter mig Intels sätt att resonera när man skickar ut patchar som i grundläget, av citatet att döma, inte åtgärdar det som man i så fall skulle ha i syfte att åtgärda genom att applicera själva patchen på ett system.

Man får ju anta att de ser det som ett potentiellt säkerhetshot då de bemödat sig att utfärda en patch mot det, eller hur?

Hade hellre sett att valet stod mellan att applicera patchen på systemet eller inte, dvs. om man applicerar patchen är standardläge skyddad+prestandaförlust vs. oskyddad, utan prestandaförlust.

Gillar verkligen inte trenden mot att patchar som förebygger potentiella -men svårutnyttjade- säkerhetshot skall behöva någon slags manuell handpåläggning och aktiveras likt en "feature".
Även om man inte påträffat saker i det vilda ännu lär det finnas stater och företag som jobbar dagarna i ända med att finna sårbarheter och sätt att utnyttja dessa, dem lär inte vara de första som informerar tillverkarna om ev. brister de upptäcker.

Självklart måste man utfärda en patch! Det finns en teoretisk möjlighet att detta påverkar ett system och kan ju finnas någon som av väldigt speciella skäl faktiskt är påverkad. Vad man kan med extremt hög sannolikhet kan säga är att patchen är helt onödig för nära 100 % av användarna.

Microsoft lyckade ju inte ens hitta ett fall där det är teoretiskt möjligt att utnyttja sårbarheten, även om de gjorde det måste ju någon lyckas göra en fungerade attack (något ingen verka ha orkat ens föröka göra för de övriga svagheterna där det är teoretiskt möjligt att utnyttja sårbarheten).

Och är precis det du skriver sedan jag efterfrågat i detta fall. Spectre variant 1 bör man absolut patcha, den är en reell risk då den kan utnyttjas via webbläsaren.

Men övriga borde vara möjliga att välja bort. Nog ändå vettigt att köra "opt-out" och inte "opt-in", d.v.s. gör man inget aktivt patchas systemet.

Vet man med sig att man inte har okända personer som kör virtuella instanser på sin dator, samt man anser att risken att bli smittad av virus och det viruset väljer meltdown eller spectre variant 2 för att försöka få admin/root rättigheter (i stället för att ta den väsentligt enklare vägen via kända "local privilege escalation" buggar) är tillräckligt låg för att ignoreras bör man ha möjligheten till "opt-out".

Linux gör detta helt rätt. Där är det möjligt att göra "opt-out" både permanent (argument till kärnan när man bootar) men även runtime via sysfs.

Att det till och med går att göra runtime visar att man på Linux-sidan har en väsentligt mycket större förståelse för att det finns vissa fall där dessa "mitigations" orsakar väsentligt mer problem än de löser. Men man vill ändå göra det så bra som möjligt, d.v.s. här kan man ha ett system som bara plockar bort relevanta patchar och bara i fall där man kanske köra någon specifik tjänst som drabbas väldigt hårt. Övrig tid kan systemet vara patchat.

Care About Your Craft: Why spend your life developing software unless you care about doing it well? - The Pragmatic Programmer