Forskare upptäcker nya sätt att utnyttja Spectre och Meltdown

Detta (från rapporten) måste ju alltid vara sant, även för ARM/POWER/RISV-V/MIPS och andra med "loose memory models"

"We use the definition of coherence preferred by notable related work [15,14]. This definition requires a cache coherence protocol to maintain two invariants: the single-writer-multiple-read (SWMR) invariant and the data-value (DV) invariant. The SWMR invariant ensures that for a given memory location, at any given logical time, there is either a single core that may write (and also read) the location or some number of cores that may only read it. Another way to view this definition is to divide the lifetime of a given memory location into epochs. In each epoch, either a single core has read-write access to the location or some number of cores have read-only access. In addition to the SWMR invariant, coherence requires that the value of a given memory location is propagated correctly."

I korthet, alla CPUer använder någon variant av MESI och vad man nu konstaterar är att de garantier en fungerande användning av MESI ger betyder att man kan använda det som (ännu) en side-channel.

En "fördel" med denna side-channel är att den tar bort kravet på tillgång till en väldigt högupplöst klocka (något som på vissa CPU-arkitekturer kan stängas av, t.ex. ARM) i "attacker process".

Ett krav här är i.o.f.s. att system har mer än en CPU-tråd, dags att damma av våra enkelkärniga modeller

Skulle mer säga att man valt att acceptera att det finns bränsle och syre i närheten av varandra, men man räknade med att ingen skulle tillföra värmen. Något tex brandkåren ofta jobbar med är att alltid.. även om risken är obefintligt, minska den ännu mer. Är som trafikverket vars vision är noll-vision.

Så ursäkten att "det blev ett problem" är skit snack. Rent ut. Det är en politisk ursäkt när allt går åt helvete för man missat få bort bränslet. Man valde att acceptera denna risk, för att vinna andra saker, och nu sitter vi här.

Detta är lika stor katastrof imho som MGM Grand branden. Man hade undantagit sprinklers i kasino-våningen för "där är alltid folk". Tills man stängde restaurangen under natten senare... och där kunde en liten brand starta och hinna bli stor i lugn o ro. Och när branden då kunde ha stoppats av sprinklers, fanns inga. Det är samma j*vla slarvighet att man accepterade den risken, för man "antog" något.

Och virtuella maskiner har varit en sak som både funnits, och använts långt innan molnet. Vet själv jag hade någon VM redan med Win 7 för att kunna köra XP-mode för en släkting. Och detta bara för hemmabruk... företaget har haft detta innan dess.

Så att detta är något nytt... nej. Det var kanske nytt 2005... men inte 10 år sedan. Det var bara att man som sagt, accepterade "risken", vilket är vad de nu ska stå till ansvar för. Deras risk var felbedömd, och har nu bitit dem i röva, och detta ska inte skyfflas under mattan för några dumma undanflykter.

Och varför i helvete skulle jag ha en brödrost som server?
Detta är inte, kommer inte, lär aldrig vara ett alternativ.

Att man måste nu börja om. Helt. Dvs hitta ett nytt sätt att göra sin "out-of-order" design, med säkerhet i tanken förstår jag inte görs på en dag.

Men att skylla bort sitt val på en bristfällig design är lika tramsigt som en byggnadsingenjör som skyller bort på annat när ett hus rasar/brinner och dödar folk. Har du tagit ansvaret på att bygga det, ska du också se till att det är säkert, oavsett CPU/Byggnad, design eller what ever.

Så snälla, sluta försvara detta nötter. De har gjort sin design. De har gjort sitt misstag, och ska ha fan för det.

Alla CPU-designer med riktigt hög IPC är extremt beroende av:

• kunna köra saker i "fel" ordning, "out-of-order"

• spekulera kring var framtida läsningar kommer ske och om villkorade hopp kommer tas eller ej

• hålla "working-set" i minne med väsentligt lägre latens väsentligt högre bandbredd

Ta bort en av dessa och se prestanda ta en rejäl nosedive. Du hävdar alltså att det inte är värt att ha dessa teoretiska problem på skrivbordet mot att få väsentligt högre prestanda?

Självklart måste detta lösas i system som körs i datacentret, men just nu är det ett icke-problem på skrivbordet (undantaget Spectre Variant 1, men det är fixat). Det kommer tyvärr nog ge en negativ effekt på prestanda där man fixar det, men i de fall problemet är ett reellt problem finns liksom inte så mycket till alternativ.

Varför är då punkterna ovan så extremt kritiska? Ljusets hastighet är tyvärr inte oändligt, vilket betyder att latens är allt mer den primära flaskhalsen för ökad hastighet. Alla är metoder för att "gömma" den verkliga kommunikationslatensen mot RAM. Så kanske skylla på Einstein?

Vilken väsentligt högre prestanda? Du måste ju sakta men säkert patcha bort den!
Vf är det för nytta med prestanda du inte kan ha, om du vill ha någon säkerhet?

Och nu kör vi med undanflykterna igen. Trots icke-problem, måste vi ju ändå patcha överallt, eller hur? Oavsett processor och användande så fick vi alla dessa Meltdown/Spectre patchar.

Nej.. jag skyller på de som valde att "gömma något" utan att tänka på vem fan som kan gräva upp det. Sluta med de dåliga "politiska ursäkterna" nu ffs.

Vill bara påpeka att jag har aldrig någonsin designat en CPU, så har ingen anledning att "försvara" något med "politiska ursäkter".

Det är bara ett konstaterande av det aktuella läget + ett personligt påstående om att det just nu är ett icke-problem för de flesta skrivbordsanvändare eftersom "attacker process" kravet inte är uppfyllt (om man nu inte har virus/malware, men då finns ju enklare sätt att ta över datorn).

Det här är ju långt ifrån det första problemet man haft under väldigt lång tid då det helt enkelt inte var ett problem. När det väl blev ett problem kunde nästan vem som helst förstå varför... Det är bara att acceptera att detta är varken första eller sista gången vi ser något likt detta.

Är ju absurt att påstå att hela industrin skulle ha vetat om detta och mörkat det under alla år: ingen kunde se helheten innan det fanns en väldigt stor drivkraft att bena ut den! Men visst, det är en möjlighet.

När sådant likt detta väl händer kan man välja att stå och sura samt ondgöra sig över hur det kunde blir så här (det brukar vara förvånansvärt populärt). Eller så konstaterar man: det har tillkommit kunskap i universum som förändrar vissa saker, låt oss agera på bästa sätt efter de nya förutsättningarna.

Det jag vänder mig emot i citatet från SweC-artikeln är just "troligen inte kan åtgärdas genom ändring i hårdvaran". Vi vet med 100 % säkerhet att alla dessa svagheter kan fixas, finns flera sätt för varje svaghet. Problemet just nu är att det inte är helt enkelt att hitta en metod som fixar problemet utan att allt för mycket påverka prestanda negativt alt. vara allt för komplicerat.

Är inte heller det rapporten säger, den påkar att en HW-lösning för varianten man beskriver där kommer antagligen behöva utformas lite annorlunda jämfört med en HW-lösning för det som beskrivits tidigare. Finns absolut sätt att lösa problem i båda fallen.

Sista påståendet är egentligen lite som att säga att vatten är blött

Dagens system kommer finnas kvar under väldigt lång tid, vilket betyder att fixar i programvara behöver finnas under överskådlig tid. Finns i många fall inget jätteenkelt sätt att ha två separata kodbaser och även i de fall det är möjligt vill man hålla antal versioner till ett minimum p.g.a. kostnad för test och liknande.

Om vi redan har en fungerande lösning i programvara, som inte enkelt kan tas bort även om en viss krets behöver det, lär det inte finnas så stort tryck på att ta fram en lösning (om det inte råkar gå att göra på ett sätt som i princip inte kostar något).

Vi ser också att Spectre kan ta många former, fler lär upptäckas framöver. Rätt svårt att rätta problem som vi ännu inte är medvetna om.

Men vi kommer säkert rätt snabbt få se en ny generation CPU som gör det väsentligt svårare att i praktiken utnyttja Spectre. Det är ofta allt som behövs.

Vi som kommer från Norrland vet att det finns väldigt mycket skog där, d.v.s. brännbart material. Finns också massor med frisk luft, luft innehåller rätt mycket syre. Räcker med ett blixtnedslag eller en oförsiktig kampare för att alla tre komponenter för en storbrand ska uppfyllas. Tror ingen argumenterar för att lösningen är att jämna skogen med marken...

Man måste väga risker mot uppsidan att leva med risken. Vi vet att transaktioner med kreditkort har en rad svagheter. Här är måttstocken för risk kontra värde väldigt enkel: så länge som kostnaden för att hantera de problem som uppstår är långt mindre jämfört med vinsterna med kreditkortstransaktioner så kommer systemet leva vidare. Gäller även skogen, fördelarna med att behålla den överväger vida riskerna.

Samma sak med Spectre/Meltdown. Går ju redan i dag att helt eliminera risken att drabbas av Meltdown/Spectre, i de flesta fall motiverar inte kostnaden på långa vägar risken (framförallt inte på skrivbordet där risken just nu är otroligt låg). Om/när en tillräckligt billig lösning på problemet finns kommer det också lösas, för då blir risk/kostnad kvoten "tillräckligt" hög.

Edit: pratar här om helt generella HW-lösningar, redan nu har vi ju "plåster" för dessa problem i form av förändringar i programvara. Dessa lösningar är inte perfekta, men "done is better than perfect". De löser det omedelbara problemet, i datacenter är ju dessa attacker praktiskt möjliga att utnyttja så är bara att acceptera nuvarande lösning fram till en bättre dyker upp.

Kan vi se början på x86 fall? Ett problem med x86 jämfört med t.ex. Aarch64 och kanske än mer RISC-V är att kretsar baserad på den förra tar väsentligt längre tid att validera. Om vi nu ser ett hårt tryck på att fixa detta i kisel är det riktigt dåliga nyheter för x86-tillverkarna. Klagar inte då jag håller alla tummar för RISC-V projektet, men på serversidan är Aarch64 en långt mer realistiskt utmanare inom överskådlig tid (framförallt givet den tsunami av 64-bitars ARM serverkretsar vi sett senaste året).

VW fuskade medvetet, så vitt vi vet kände ingen till dessa problem innan 2017. Ser du skillnaden?

Genom hela min karriär har boken "The Pragmatic Programmer" varit bibeln, även här tycker jag boken sätter fingret på vad som är mest kritiskt att fokusera på.

Fix the Problem, Not the Blame
It doesn’t really matter whether the bug is your fault or someone else’s—it is still your problem, and it still needs to be fixed.

D.v.s. förutsatt att detta är ett ärligt misstag, vilket normalt buggar i alla dess former är, så är det enda viktiga nu att fixa problemet på bästa sätt. Vad vore värdet i att gräva vems "fel" detta är?

Vad rapporten beskriver är en automatiserad metod för att kunna skapa en "attacker process" för precis alla drabbade kretsar. Ser inte hur det på något sätt förändrar Intels situation där man redan tagit fram proof-of-concept "manuellt". Det gjorde det däremot väldigt mycket enklare på övriga kretsar.

Man har använt Intels CPUer att verifiera sina idéer på, av allt att döma främst därför att forskarna verkar sitta på Mac-baserade datorer.

Så vilken är värst drabbad:

Intel där man har fungerande proof-of-concept, vilket också betyder att man har en möjlighet att verifiera att de motmedel man tagit fram fungerar.

Övriga där man saknar proof-of-concept, vet att attackerna är möjlig men har inga möjligheter att verifiera om motmedel fungerar. (Nu är det inte sant, allt tyder på att ARM internt har fungerande proof-of-concept för drabbade Cortex A modeller).

VW kände till problemet, Intel/AMD/IBM/ARM kände (så vitt vi vet nu) inte till problemet innan 2017. Ser du skillnaden?

Finns mycket klokt nedskrivit i böcker, men saker kanske inte längre räknas om det inte ligger på YouTube

?

Under detta halvår tog man fram en OS-patch för Meltdown, som numera är inkluderade i alla populära OS.

AMD och Intel samarbetade kring hur man skulle utöka x86 ISA med nödvändig kontroll av branch-target-buffers. ARM lurande ut hur man kan använda redan existerande funktioner för samma sak.

Alla kiseltillverkare lär redan från dag #1 ha börjat fundera på hur detta ska angripas i på kretsnivå. Man får inte ut en x86-krets på kortare tid är 12-18 månader. T.ex. så är Zen2 klar sedan någon månader tillbaka, varför kommer vi inte se produkter innan 2019? Kanske för att man inte kan färdigställa validering tidigare (Ice Lake har garanterat varit "klar" minst lika länge).

Till och med enklare Cortex A kretsar, som är betydligt enklare att validera jämfört med high-end x86, brukar ta runt ett halvår från de är "klara" på IP-nivå till att de första serietillverkade kretsarna hittar ut.

Det har gnällts om att Coffee Lake släpptes efter Intel fick kännedom om detta. Ja, och det finns idag lösningar för Spectre/Meltdown.

AMD kände också till detta innan de släppte Epyc och ThreadRipper. Vad skulle de göra? Skita i att släppa Epyc och fortsätta visa röda siffror?

Detta är (just nu i alla fall) ett icke-problem på skrivbordet. Vi har ju både hängsle och livrem, dels är inte kravet på "attacker process" uppfyllt och dels finns skydd i form av förändringar av kritisk programvara.

Svårt att se någonting här som tyder på att man inte tar ansvar. Det är inte på något sätt att likställa med VW då man där insåg att det fanns ett problem och man "löste" problemet genom att medvetet fuska. I Spectre/Meltdown har man gjort väldigt mycket under det halvår som gått, inget av detta innefattar att sopa problemet under mattan.

Roadmap från början av 2017, viktigast i sammanhanget: före forskarna lämnade ut information om Meltdown/Spectre till CPU-tillverkarna

CFL-S i Q3 och den verkliga lanseringen var precis i slutet av Q3, så om den var flyttad var den i alla fall inte tidigarelagd. Även "Gemini Lake" släpptes precis enligt detta schema.

CFL-S är en konsumentplattform, det mest prestandakritiska denna typiskt används till är spel. Prestandapåverkan i spel är så här långt omätbar (skriver så här långt för spectre variant 2 patcharna saknas här, både AMD och Intel har lämnat mikrokodspatchar för detta till moderkortstillverkarna som gissningsvis jobbar på uppdateringar).

Och av allt att döma säljer i7-8700K rent lysande.

Så hoppas det bidrar till en lite skönare helg nu när det visat sig att hela CPU-industrin är kanske inte i maskopi mot kritiskt granskande kunder!

Ska vi slå vad?

https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-5753
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-5715
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-5754
Detta är Spectre 1 och 2s, samt Meltdowns sårbarhetsinfo.
Vill du vara så vänlig och notera datumet?

Assigning CNA
Intel Corporation
Date Entry Created
20170201

Mao.. det anledning att misstänka att de visste om det redan när den roadmappen ovan gjordes. Behöver inte vara just då dock, men att det just är Intel som skapat alla 3 samt att just februari är ca 1 månad efter man först lyckats genomföra attacken.

"Spectre was discovered independently by Jann Horn from Google's Project Zero and Paul Kocher in collaboration with Daniel Genkin, Mike Hamburg, Moritz Lipp and Yuval Yarom.[when?] Microsoft Vulnerability Research extended it to browsers' JavaScript JIT engines.[4][16] It was made public in conjunction with another vulnerability, Meltdown, on January 3, 2018, after the affected hardware vendors had already been made aware of the issue on June 1, 2017"

Och där är datumet när alla tillverkare fick reda på det, så vid den tidpunkten visste alla (AMD/Intel/ARM osv) om det.

Men tester fanns betydligt tidigare än så:
"This technique was used to successfully attack GnuPG, AES and other cryptographic implementations In January 2017, Anders Fogh gave a presentation at the Ruhruniversität Bochum about automatically finding covert channels, especially on processors with a pipeline used by more than one processor core"
(*)

Det finns situationer som tydligen sträcker sig så långt bak som 2002 där man egentligen verkar ha råkat använda denna bugg, dvs mer än 15 år sedan, på just Intel Processor där de lyckats ta krypteringsnycklar via en cache attack. Slump? Eller valde man bara att sopa detta under en matta kanske?

Så här såg det ut innan detta (den info som fanns 2016, innan denna bugg upptäcktes)

https://www.sweclockers.com/nyhet/22663-intels-produktplaner-for-2017-och-2018-rojer-cannonlake-och-coffee-lake

Från början var ju Cannon Lake helt tänkt till laptops, men plötsligt har allt landat på Coffee Lake istället.

Samtidigt så har Intel hunnit "laga" (eller ja.. bättra på) Cannon Lake... Hur i böveln tror du de hunnit göra detta om de bara vetat om det så kort tid? Jo de försenade Cannon, släppte Coffee så snabbt de kunde få tillverkat dem (något Intel aldrig gjort förr i modern tid btw).

Nej... CPU-industrin är verkligen inte ren bransch, och du måste sluta försvara den. eller börja ta advokat licens.
Trevlig helg på dig oavsett

PS. Det finns mer än spelprestanda, något du själv älskar att påpeka.

Missade denna.

Rent tekniskt handlar Meltdown/Spectre om "side-channel", inte "covert channel". Dessa två är inte samma sak.

Covert channel: process A och B kan kommunicera trots att systemets säkerhetspolicy inte tillåter kommunikation mellan processerna, ibland kan kommunikationen även ske på ett sätt som OS-kärnan/hypervisor inte kan "se". Första exemplen på detta dateras till 60-talet!

En modern desktop PC har en lång rad kända "covert channels" p.g.a. saker som SMT (delade cache/ALUs) och andra former av delade HW-resurser. "Covert channels" är ett icke-problem i "vanliga" system då det krävs att båda processerna är med på noterna. I system där man kräver hård separation mellan processer får man göra ganska mycket som påverkar prestanda negativt för att upprätthålla denna separation.

Side-channel: process A kan få ut information om process B tillstånd utan att systemet tillåtet detta eller att process B är medveten om det. Första exemplen dateras tillbaka till de första datorerna som skapades på 40-talet!!! Idag är detta man måste tänka på vid design av t.ex. krypteringsalgoritmer, annars blir direkt t.ex. SMT en side-channel.

Så detta är i sig absolut inget nytt.