Sårbarhet hos Intels färska arkitekturer uppdagas

Vad håller Intels validering på med egentligen? Om de åkte dit på Meltdown och Spectre så är ju det en signal att de behöver skärpa sig, men här lyckas de missa helt nya buggar efter det (buggen finns inte i Skylake).

Är det på moderkortet man uppdaterar firmware/bios då eller?

Ser att det finns en ny firmware från 2022-05-04: "- Update Intel Micro code for security vulnerabilities", kan det vara detta?

Nog bäst att släppa en patch om sex månader, efter alla konsumenter gjort sina val och köpt produkterna, som sänker prestandan med 15% och hänvisa till denna och några till säkerhetshål.

Sen om några år vill man ju köpa nåt nytt där man kan få tillbaka den där förlorade prestandan!

Det är kanske inte så konstigt om fler sårbarheter hittas just nu, hittas ett par problem så hamnar fokus på att hitta fler och fler personer ägnar sig åt leta.

Sen är det även mycket större fokus på säkerhet idag. På 90-talet när ungefär 500 personer hade internet var det ingen som riktigt brydde sig.

Det är ytterligare en anledning naturligtvis, samt att företag och myndigheter världen över som har ett extremt skyddsbehov är villiga att betala för att hitta luckor på ett helt annat sätt, och då är det klart mer som hittas.

Ni pratar om samma sak: SQUIP. Mer detaljer här, men om jag summerar: om du lyckas få din process att gå på den andra tråden av två som går på samma kärna (dvs, via SMT) så kan du läcka lite information genom att detektera hur upptagen den andra tråden är. Vilket är lite Jaha? Om din algoritm är konstruerad för att ta lika lång tid oavsett resultat (constant-time algorithm) så skall det inte spela någon roll. Det kanske kan bli något i nästa steg eller det efter detta, men i dagsläget så är de inte riktigt framme. Det är ingen nyhet än (hade det varit det, hade jag skickat in det som ett tips, för jag kände till det).

Då vet man ju att någon har goda möjligheter att komma åt din data. Med alla dessa sårbarheter vet man inte. Typ Schrödingers sårbarhet.

@Yoshman: Jag kan hålla med om att det blev lite för mycket liv om Spectre, men som jag ser det är det en skillnad på Spectre och Meltdown. Spectre handlar om att man tar genvägar för att tjäna prestanda, och nu åkte man dit med ett säkerhetsproblem. Meltdown är bara en bugg. Det finns ingen anledning att inte filtrera bort den förbjudna läsoperationen tidigare, och det är t.o.m. en optimering att göra så. På så sätt är SQUIP och Spectre samma sak, men detta är precis som Meltdown en bugg (eller flera).

Jag hade inte hört att Apples designer råkade ut för Meltdown, har du en länk till nåt om det?

Det är väldigt implicit här, men går att få informationen direkt från Apple

"Meltdown is a name given to an exploitation technique known as CVE-2017-5754 or "rogue data cache load." The Meltdown technique can enable a user process to read kernel memory. Our analysis suggests that it has the most potential to be exploited. Apple released mitigations for Meltdown in iOS 11.2, macOS 10.13.2, and tvOS 11.2, and also in Security Update 2018-001 for macOS Sierra and Security Update 2018-001 for OS X El Capitan. watchOS did not require mitigation."

Varför lägga in skydd för Meltdown i iOs och tvOS om det bara vara ett Intel problem... M1/M2 verkar dock inte vara påverkade, utan detta gäller de CPU-modeller som var aktuella för iOS/tvOS på den tiden.

Sen är väl ändå Meltdown och Spectre precis lika mycket "bug" ur ett logiskt perspektiv, båda gör det möjligt att potentiellt få tag i information som inte ska vara tillgängligt enligt specifikation. Det som primärt gjorde Meltdown värre var att det faktiskt gick att skriva en fungerande PoC som inte krävde helt löjliga timingkrav.

AMD hade inte bara "tur" med Meltdown. De hade också tur att TakeAWay "bara" läcker meta-data (den läcker inte direkt information, utan information om hur information används...), för den är likt Meltdown (och olikt Spectre och SQUIP) relativt enkel att utnyttja även i praktiken.

Så just den aspekten borde lyftas fram mer, d.v.s. är det möjligt att utnyttja sårbarheten i något som liknade ett realistiskt scenario? Ur den aspekten är Meltdown bland det värsta som upptäckts så här långt!!!

Det verkar som man slipper en del säkerhetshål om man har en in-order design och ingen SMT.
Men är det värt all prestanda man ger upp?
Beror väl lite på vad systemet ska användas till.

Exempelvis Raspberry Pi, 1-3 är in-order design.
Har man ett fall där prestandan av en Raspberry Pi 3 räcker så känns det som ett bättre val än att bygga något fullt Core i5, i7, i9 system.

Om en Pi 3 bara är lite större än enbart processorn för Core systemet.
Drar mindre under load än vad Core systemet gör under idle.
Kostar mindre än en tiondel att köpa in.
Har färre säkerhetshål?
Fler GPIO pins.

Vissa datoranvändare verkar tro/tycka att alla datorer måste klara av 4K gaming at 60+ FPS.

Men ska man bara göra enklare hemautomation eller dylikt behöver man inte bygga en fulltower dator med custom vattenkylning för ändamålet.

För vissa ändamål kan det räcka med en Raspberri Pi eller motsvarande.
Ibland kanske t.o.m. en som är långsammare än Pi 4.

Det ser ju illa ut, men om summeringen högst upp i samma artikel säger:

Så artikeln motsäger sig själv här.

Om vi tar en metafor: vi driver en järnväg, och vill komma så fort som möjligt från A till B. Vi kan gena över ett skyddsområde, om vi ser till att passagerarna inte kan titta ut när vi passerar det området. Någon upptäcker ett hål så att de kan titta ut, och vi kan inte laga det, så vi får dra om järnvägen. Spectre är att vi tog en genväg över ett hörn, och att dra om järnvägen innebär att vi måste göra vägen längre. Meltdown är att tåget ibland kör in på ett stickspår i skyddsområdet där det måste vända. Att tåget kör in på stickspåret är ett misstag som aldrig borde ha gjorts, så det kostar oss inget att vi måste sluta med det.

På samma sätt är buggen som den här artikeln beskriver ett misstag som aldrig borde ha gjorts. Spectre däremot är en effekt av en konstruktion som försöker ta så många genvägar som möjligt. Det är mer av en kalkylerad risk, så att säga.

Det sista håller jag helt med om, men det är ofta inte så tydligt i den tidiga fasen hur lätt det är. Forskarna som skriver artiklarna vill ju ofta blåsa upp det till ett massivt problem, och att kritiskt granska det är inte alltid så lätt.

Att både Spectre och Meltdown existerar beror på samma grundläggande sak: de kommer av optimeringar som ger högre prestanda, men som i båda fallen visat sig öppna upp för data-läckage.

Meltdown hände därför man spekulativt läste in data innan man kollade att anropade säkerhetsdomän överhuvudtaget får läsa den delen av minnet. Accepterar man att Meltdown-problemet finns får man bättre prestanda då det frikopplar ordningen mellan två minnesaccesser. Så i din metafor är lösningen här just: vi får göra vägen lite längre, d.v.s. man måste vänta in check:en av ena minnesaccessen då den avgöra om man överhuvudtaget får göra den andra accessen.

Resultatet i en CPU som har Meltdown-problematiken är att det kommer upptäcka att man inte får göra accessen, i det läget gör den då en "rollback" och visar inte resultatet för anroparen. Problemet är att då man ändå gjorde accessen spekulativt, kan man indirekt hitta kvarvarande effekter (vilket gäller för all form av spekulativ läsning som i slutändan misslyckas, är bara så att vissa former av spekulering, OoO-optimering, måste explicit hindras av säkerhetsskäl).

Vad det gäller Apple artikel: har du kolla på changeloggar från Apple, Microsoft, m.fl.? De kan ibland göra rätt stora och viktiga förändringar, det som officiellt skrivs i artiklar likt den Apple hade här är typ "fixed stuff...". Att man skriver det ett på ett ställa får noga väga betydligt tyngre än att man utlämnar det på ett annat ställe (för man skriver inte motsatsen, man bara utelämnar informationen)

Edit: och Apple skriver vidare i sektionen om Meltdown

"Our testing with public benchmarks has shown that the changes in the December 2017 updates resulted in no measurable reduction in the performance of macOS and iOS as measured by the GeekBench 4 benchmark, or in common Web browsing benchmarks such as Speedometer, JetStream, and ARES-6."

Varför ens fixa + testa om man inte hade problemet?

Sen hävdar man max 2,5 % försämring för Spectre relaterade fixar, låter väldigt lågt och undrar hur mycket testing som gjorts externt av deras fixar (med bakgrund att det tog 5 år att lura ut att AMDs fixar för Spectre V2 inte var tillräckligt...).

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.

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.

Ä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.