Sårbarhet hos Intels färska arkitekturer uppdagas

Permalänk
Datavetare
Skrivet av mpat:

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

Skrivet av mpat:

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.

Visa signatur

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

Permalänk
Medlem
Skrivet av Valonen:

Är det bara jag som inte fattar dessa sårbarheter? Alltså, är det fara för liv och hälsa och/eller Ivan den lömske hackaren, eller en sårbarhet skapad av nördar i ett nördlab?

Tänker att flera sårbarheter har ett flertal förutsättningar:

1. Fysisk tillgång.
2. Biologisk kännedom och/eller släkt.
3. En gnisttändning mellan vederbörandes skinkor måste ske samtidigt som övriga villkor.
4. En Phd i datavetenskap.
4. En arg tonåring som vill ge igen.
5. Mormor/farmor som tröttnat på att du aldrig ringer tillbaka.

För att förenkla lite.
Sårbarheter så här djupt inne i ett system ser oftast inte särskilt farliga ut om man bara läser buggbeskrivningen, en massa villkor skall uppfyllas osv. Men för att slutanvändaren ska kunna använda funktionen där buggen finns så måste den läggas till i OS, drivers osv och dessa har definitivt fysisk tillgång till ditt system, därefter skriver någon ett program där funktionen används, det finns alltså många lager mjukvara som kan trigga buggen och en bugg på så låg nivå kan vara väldigt svår att täta.
Ytterligare en risk är att den kan användas oavsett OS.

Permalänk
Medlem
Skrivet av MegaMuztek:

För att förenkla lite.
Sårbarheter så här djupt inne i ett system ser oftast inte särskilt farliga ut om man bara läser buggbeskrivningen, en massa villkor skall uppfyllas osv. Men för att slutanvändaren ska kunna använda funktionen där buggen finns så måste den läggas till i OS, drivers osv och dessa har definitivt fysisk tillgång till ditt system, därefter skriver någon ett program där funktionen används, det finns alltså många lager mjukvara som kan trigga buggen och en bugg på så låg nivå kan vara väldigt svår att täta.
Ytterligare en risk är att den kan användas oavsett OS.

Okej, tack då är det kanske lättare att förstå.

(Smyger in frågan ändå: Så det är inte helt fel att det måste till en gnista mellan skinkorna)?

Visa signatur

Chassi: Corsair Obsidian 500 RGB SE / Systemdisk Samsung 980 PRO SSD: Samsung 850 PRO 250GB / SSD: Samsung 850 EVO 250GB / SSD: Crucial MX300 1TB / CPU: Ryzen 7 3800X @ 4,2 Ghz / Kylning: Noctua NH-D15S push/pull / GPU: MSI 3080Ti SUPRIM X / PSU: Corsair RM1200i / MB: ASUS X470-f Gaming / RAM: HyperX Fury 2x16GB 3600 mhz / OS: W10 / Mus: Logitech G903 / TB: Logitech G915 TKL Wireless / Ljud: Sound BlasterX Pro-Gaming AE-9, Blue Yeti , Sennheiser HD660S, Skärm: Acer Predator X34P @3440x1440 UltraWide

Permalänk
Medlem
Skrivet av Yoshman:

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 vet att Intel fokuserar stenhårt på att hitta läsoperationer ganska långt fram i koden för att få dem gjorda så snart som möjligt, och det finns goda poänger skäl att göra det. Mitt motargument handlar om energin de spenderar i det här fallet. Intel har i många år sagt att en förändring som ökar energiförbrukningen med 1% måste leda till en prestandaökning om 2%, dvs det är viktigare att spara energi än att göra det absolut snabbaste. Om man skall springa hela vägen ut till huvudminnet för att läsa något så tar det massor med energi. TLB finns normalt sett tillgänglig med kort latency, och den måste ändå läsas innan läsoperationen går till L2. L1 är virtuellt indexerad, men L2 och senare är normalt sett fysiskt indexerade. Du är ändå där och läser, kolla om du faktiskt borde göra det när du ändå kollar upp adressen.

Detta skulle innebära att man kan läsa från L1, men inte L2. Man tappar bara prestanda om TLBn är full och just den raden måste hämtas från page table i huvudminnet medan datan i fråga fanns i någon cache. Det kan inte vara vanligt.

Sen är det naturligtvis så att allt beror på hur vanligt något är. Om simuleringarna bygger på välskriven kod som aldrig försöker sig på några dumheter så är det klart att man aldrig kan ”vinna” på en sån här förändring - det fallet när man hade avbrutit läsningen hade ju aldrig inträffat.

Citat:

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.

Jaså OK. Jag har läst change-loggar för mååånga år sen, men inget nyligen. Minns att jag hade tänkt leta upp den för goto fail: för att se om det stod nåt kul, men jag gjorde aldrig det.

Visa signatur

5900X | 6700XT

Permalänk
Medlem
Skrivet av Valonen:

Okej, tack då är det kanske lättare att förstå.

(Smyger in frågan ändå: Så det är inte helt fel att det måste till en gnista mellan skinkorna)?

Om du använder gnistan mellan skinkorna metaforiskt så är du inte helt ute och seglar, gnistan i sig är inte farlig, men om du fiser samtidigt kan det bli rätt otäckt 🙂

Permalänk
Medlem
Skrivet av MegaMuztek:

Om du använder gnistan mellan skinkorna metaforiskt så är du inte helt ute och seglar, gnistan i sig är inte farlig, men om du fiser samtidigt kan det bli rätt otäckt 🙂

Hahaha, tack för svaret!

Visa signatur

Chassi: Corsair Obsidian 500 RGB SE / Systemdisk Samsung 980 PRO SSD: Samsung 850 PRO 250GB / SSD: Samsung 850 EVO 250GB / SSD: Crucial MX300 1TB / CPU: Ryzen 7 3800X @ 4,2 Ghz / Kylning: Noctua NH-D15S push/pull / GPU: MSI 3080Ti SUPRIM X / PSU: Corsair RM1200i / MB: ASUS X470-f Gaming / RAM: HyperX Fury 2x16GB 3600 mhz / OS: W10 / Mus: Logitech G903 / TB: Logitech G915 TKL Wireless / Ljud: Sound BlasterX Pro-Gaming AE-9, Blue Yeti , Sennheiser HD660S, Skärm: Acer Predator X34P @3440x1440 UltraWide