Om vi kokar ner situationen så långt det går: Meltdown bygger på att en process läser en adress som den inte får, och det upptäcks inte förrän operation går till ”retire” (vet faktiskt inte vad alla dessa termer heter på svenska, så det blir lite svengelska). Problemet undviks om man kollar access vid issue istället. Jag tycker att det är en bugg att man inte kollar vid issue. Access rights kollas i TLB, och i medel måste detta vara snabbare än att hämta en slumpmässig adress som kan komma från huvudminnet - för att inte tala om hur mycket energi det sparar
Det snabbaste måste vara att man skickar ut begäran till TLB samtidigt som man försöker läsa. Om man då möjligen lyckas läsa en gång, för att just den sidan inte låg i någon TLB-cache men svaret man var ute efter låg i L2, så kommer det inte att gå att läsa mer än en byte. Nästa gång man försöker samma trick finns den sidan i TLB-cachen och processen dödas för snabbt. Försöker man stampa över hela TLB-cachen för att tömma, så minskar läshastigheten i läckan markant. I vilket fall är det en snubbeltråd som gör attacken svårare.
Det är mer komplicerat än så!
Vad det handlar om är huruvida det överhuvudtaget ska vara möjligt att göra spekulativa minnesoperationer i en högre priviligeringsnivå än den man för tillfället befinner sig i.
Lätt att direkt säga: men uppenbart att det inte ska vara möjligt!!!
Fundera då igen, varför har Intel, VIA, IBM, SUN (UltraSPARC verkar också ha buggen), Apple, ARM alla lyckats gjort samma miss? AMD var faktiskt undantaget här!
Därför att om man gör en CPU med väldigt mycket resurser att köra saker "out-of-order" så vill man utnyttja detta. Meltdown hände därför man ville även optimera fallet där man gör väldigt frekventa systemanrop och systemanropen utför ett par minnesoperationer.
Vad alla som är mottagliga för Meltdown har gemensamt är att de delar upp steget att läsa minnet från steget att verifiera att man har rätt att läsa det. Vinsten är att man kan inte göra "retire" på verifieringssteget innan man faktiskt vet vilken priviligeringsnivå CPUn befinner sig i när operationen tar effekt, samtidigt som man kan spekulera i att "det går nog bra" och låta själva dataoperationen gå igenom och därigenom "låsa upp" spekulativ körning av efterföljande beroende instruktioner (som inte kan nå "retire" innan verifieringsteget på minnesoperationen gör det, men fallerar det gör man roll-back på allt)
Gör man väldigt många systemanrop är det till och med sannolikt att det kan vara en annan priviligeringsnivå när en minnesaccess tar effekt jämfört med när den skulle ha kunnat exekverats.
Alternativet är att inte ens påbörja minnesoperationen innan man rätt ut att nuvarande priviligeringsnivå inte kan ändras fram till att man logisk ska köra minnesoperationen. Gissar att det är lösningen man nu kör, men det tappar tyvärr en hel del ILP i fall som väldigt frekvent hoppar mellan userspace/kernelspace.
Ett enklare experiment man kan göra är att t.ex. läsa en byte i taget från en I/O-enhet utan buffring, d.v.s. tvinga ett systemanrop för varje byte. Kör sedan det på en Intel CPU som är mottaglig för Meltdown (och kör utan fixar) mot en Ryzen CPU: Intel CPUn kommer vara långt snabbare på detta.
Gör om samma sak på dagens Intel, den är nu i nivå med Ryzen (vilket ändå är snabbare än den gamla modellen med SW fixar).
Sättet människor resonerar kring tid, kombinerat hur saker faktiskt händer kontra hur de "borde" hända i moderna out-of-order designer nära nog garanterar att det kommer bli den här typen av fel
Jag har inte läst Apples changeloggar, så kul är det inte att argumentera på forum. Jag var mest förvånad, för jag såg Meltdown som en väldigt Intel-specifik bugg (till skillnad från Spectre), och Apples designer liknar inte Intel speciellt. De är närmare AMD om något (med alla sina scheduler queues), med lite lukt av gamla PPC-designer.
Var inte så jag menade, fråga var om du någon gång kikat på t.ex. Apples eller Microsoft change-loggar i samband med att man fixat något lite mer hög-profilerat problem.
Läser inte heller dessa regelmässigt, men har gjort det några enstaka gånger just för att se vad man faktiskt berättar kring de saker som nog varit lite pinsamma för dem. Korta svaret är: ibland finns det en notis som "nog" refererar till det fallet, men man pratar inte precis klartext...
Så att information kring exakt vad som gjorts och påverkats av säkerhetsfixar är iffy är rätt väntat.
Care About Your Craft: Why spend your life developing software unless you care about doing it well? - The Pragmatic Programmer