Nya erbjudanden i Komplett Geek Week

Sårbarhet hos Intels färska arkitekturer uppdagas

Permalänk
Melding Plague

Sårbarhet hos Intels färska arkitekturer uppdagas

Säkerhetsfunktionen SGX är inte helt säker hos arkitekturerna "Ice Lake" och "Alder Lake", där skyddad data kan läsas på grund av en bugg.

Läs hela artikeln här

Permalänk
Medlem

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

Permalänk
Medlem

Here we go again...

A never ending story!

Permalänk
Medlem
Permalänk
Medlem

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

Permalänk
Medlem

Är det så simpelt att Intel inte gör ett tillräckligt bra jobb eller blir t.ex. AMD inte granskad lika hårt eftersom Intel används i majoritet?

(Oavsett gör de ju givetvis inte ett tillräckligt bra jobb eftersom vi ser så många av dessa problem men jag menar i jämförelse till konkurrenterna)

Permalänk
Medlem
Skrivet av Korppi:

Är det så simpelt att Intel inte gör ett tillräckligt bra jobb eller blir t.ex. AMD inte granskad lika hårt eftersom Intel används i majoritet?

(Oavsett gör de ju givetvis inte ett tillräckligt bra jobb eftersom vi ser så många av dessa problem men jag menar i jämförelse till konkurrenterna)

Åtminstone en del av det handlar nog om att Intel belönar forskare som hittar säkerhetshål i deras produkter, vilket AMD inte gör. Så säkerhetsforskare kommer förstås föredra att leta efter hål i Intels produkter. Men det hittas en hel del hål i AMDs produkter också, t.ex. SQUIP som dök upp för någon dag sedan och gäller alla Zen-baserade processorer med SMT.

Permalänk
Medlem

Jag tror inte det går att göra en processor som är helt fri från säkerhetsrisker, men det känns som att det är lite väl många nu för att det ska vara rimligt.

Permalänk
Medlem

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!

Permalänk

Nä, snart drar jag fram mekaniska skrivmaskinen från förrådet istället. Mycket säkrare. Lite svår att spela på bara.

Permalänk
Medlem

Med tanke på att det rapporterades om en sårbarhet hos Ryzen för bara ett par dagar sedan, Tom's Hardware, så känns det som att det jobbas hårt på att hitta brister. Dock så verkar de flesta sårbarheter som hittas kräva tillgång till systemen som är svår att få i verkligheten och dessutom tycks det inte vara så att de flesta av dem är något hot för privatpersoners datorer.

Permalänk
Medlem
Skrivet av underd0g76:

Nä, snart drar jag fram mekaniska skrivmaskinen från förrådet istället. Mycket säkrare. Lite svår att spela på bara.

Det är ju verkligt farligt 🙂 även om någon behöver göra inbrott i ditt hem, men har man tillgång till färgbandet kan man läsa det mesta som skrivits, så skriv i koder isf 😂

Permalänk
Medlem
Skrivet av Kiono:

Jag tror inte det går att göra en processor som är helt fri från säkerhetsrisker, men det känns som att det är lite väl många nu för att det ska vara rimligt.

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.

Permalänk
Medlem
Skrivet av MegaMuztek:

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.

Permalänk
Medlem
Skrivet av DasIch:

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.

Permalänk
Medlem
Skrivet av perost:

Åtminstone en del av det handlar nog om att Intel belönar forskare som hittar säkerhetshål i deras produkter, vilket AMD inte gör. Så säkerhetsforskare kommer förstås föredra att leta efter hål i Intels produkter. Men det hittas en hel del hål i AMDs produkter också, t.ex. SQUIP som dök upp för någon dag sedan och gäller alla Zen-baserade processorer med SMT.

Skrivet av meanh:

Med tanke på att det rapporterades om en sårbarhet hos Ryzen för bara ett par dagar sedan, Tom's Hardware, så känns det som att det jobbas hårt på att hitta brister. Dock så verkar de flesta sårbarheter som hittas kräva tillgång till systemen som är svår att få i verkligheten och dessutom tycks det inte vara så att de flesta av dem är något hot för privatpersoners datorer.

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

Permalänk
Skrivet av MegaMuztek:

Det är ju verkligt farligt 🙂 även om någon behöver göra inbrott i ditt hem, men har man tillgång till färgbandet kan man läsa det mesta som skrivits, så skriv i koder isf 😂

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.

Permalänk
Datavetare
Skrivet av Korppi:

Är det så simpelt att Intel inte gör ett tillräckligt bra jobb eller blir t.ex. AMD inte granskad lika hårt eftersom Intel används i majoritet?

(Oavsett gör de ju givetvis inte ett tillräckligt bra jobb eftersom vi ser så många av dessa problem men jag menar i jämförelse till konkurrenterna)

Vet inte hur många som faktiskt har koll på vad SGX används till. I korthet kan man beskriva det lite som ett bankfack hos en bank där du alltid får ett isolerat enskilt rum där du kan kan stoppa in och plocka ur saker ur ditt bankfack utan att någon på banken har någon möjlighet att kontrollera innehållet. D.v.s. det är för kunder som vill använda bankens tjänster, men inte litar på att låta banken veta vad man säkrar där.

>99 % av alla bankkunder litar i praktiken blint på sin bank, precis som >99 % av alla AWS, Azure, Google Cloud kunder litar på att molnleverantören är reko. I det läget är SGX totalt meningslöst, sist jag kollade var det faktiskt bara Micrsoft Azure som överhuvudtaget aktiverat SGX (krävs dels att funktionen är aktiverad på OS/VM-nivå, dels att programmet explicit använder det).

Det går inte sårbarheten mindre allvarlig, är lite som att det där isolerade rummet trots allt visade sig vara avlyssnat... Men det kanske visar att en sådan här nyhet ens kommer upp på entusiast-webbplatser har rimligen att göra med att det handlar just om Intel.

SweClockers måste ju sålla bland potentiella saker att skriva, möjligen kom just denna i en tid när typ inget händer och/eller just att det var Intel. Man valde t.ex. inte att skriva om när 22 EPYC relaterade CVEs blev kända under rätt kort tid , varav en som fick namnet SEVerity (precis som i fallet här med ÆPIC kräver SEVerity "root" access, d.v.s. att den som driver servern är skurken).

Sen ska man vara medveten om att majoriteten av alla säkerhetshål som hittas, och det är många enbart relaterat till CPU/GPU, aldrig får en notis skriven utan för CVE-databasen.

Jobbet forskarna gör är ändå viktigt: de flesta av dessa sårbarheter är i praktiken helt hopplösa att göra något åt, andra är relativt enkla att fixa. Oavsett är det bättre att känna till dem än att inte göra det!

Permalänk
Medlem

Kan man få flika in att det är underbart att läsa dina förklaringar @Yoshman, du gör saker som är svåra att förstå nästan helt begripliga för en sån som mig. Tack!

Permalänk
Datavetare
Skrivet av mpat:

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

Fast alla "out-of-order" designs åkte ju dit på Spectre, så det säger väl knappast så mycket om just Intels validering. D.v.s. Intel, AMD, Apple, Qualcomm, Samsung, IBM, etc åkte alla på denna!

Sedan undrar jag hur många som är medveten om att Intel var långt ifrån ensamma om att åka dit på Meltdown, även Apple (deras egen CPU alltså), IBM och vissa Arm Cortex A åkte på den. Så här hade AMD "tur" i att de valde en liten annan lösning som just råkade göra att man klarade denna. Faktiskt lite förvånad att pressen inte gav sig på Apple kring detta, möjligen "klarade" sig Apple här då det blev likhetstecken mellan Meltdown och Intel, Apple körde ju i det läget fortfarande Intel i sina Mac:ar.

Sen är min åsikt att det blev allt för mycket hallå kring just Spectre. Finns i.o.f.s. flera varianter, men de flesta var ju nästan hopplösa att utnyttja även i kontrollerade miljöer. Det var svårt att få proof-of-concept exemplen att fungera, i praktiken fick man vara "root", se till att datorn var helt ren från alla andra program, slå av "turbo boost" och ändå fick man handoptimera timings om man inte hade exakt samma CPU-modell som den de som skrev PoC hade.

Ett exempel hur lite forskarna verkar bry sig om att följa upp Spectre var att AMDs CPU/OS-nivå fix för Spectre V2 visade sig otillräcklig, något som tydligen tog 5 år att reda ut... Givet att "korrekt" fix för något som verkar nära hopplöst att utnyttja i praktiken verkar kunna ge enorm prestandapåverkan tar jag nog risken att köra vidare "osäkert"...

"Unfortunately, further research shows that AMD is not immune to Spectre V2, and its previous measures may be inadequate, bringing performance drops of up to 54%."

Är självklart bra att man hittar problemen och fixar dem. Men just Spectre är problematiskt då den verkar så hopplöst svår att utnyttja till något vettigt, men att fixa den påverkar tyvärr prestanda på ett icke-signifikant sätt (det för alla, exakt hur mycket varierar men alla out-of-order CPU är påverkade och alla får negativ prestandapåverkan av fixar).

P.g.a. av att just denna fått sådant fokus är det svårt för någon CPU-tillverkare att göra något annat än permanent fixa problem. Men skulle föredra att man som användare skulle kunna opt-out!

Skrivet av mpat:

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

SQUIP möjliggör två saker:

Dels en generell "covert channel". Detta är långtifrån den första "covert channel" som hittats för SMT och för de flesta är tillgång till en sådan ett icke-problem.

För de som undrar: "covert channel" är en kommunikationskanal som finns mellan två olika säkerhetsdomäner, t.ex. två program på en dator, som kan kommunicera med varandra oavsett om det borde vara möjligt på OS-nivå.

Dels är det en "side channel". "Side channel" är när en process kan läsa viss information från en annan process, även fast det inte borde vara möjligt baserat på OS-policy.

Man använder "extrahera RSA nycklar" som exempel. Man visar att det, i en extremt kontrollerad miljö som är totalt irrelevant för "normalt" användare, gick att använda detta i omodifierade existerande ramverk (i detta fall använde man mbedTLS, OpenSSL användes bara för att generera nycklar).

Det jag finner mest intressant med SQUIP är inte sårbarheten i sig, den verkar ungefär lika användbar i praktiken som Spectre..., utan att det igen är ett exempel på att man antagligen kommer hitta massor med nya sårbarheter genom att utnyttja specifika val i mikroarkitekturen.

SQUIP kräver att man valt en specifik design för de köer som ligger framför "backends" exekverings-enheter. I rapporten du länkar konstateras ju att attacken inte fungerar på Intel då de har en "globala schemaläggare" medan den hade fungerat på t.ex. Apple M1/M2 om dessa hade haft SMT då just den detaljen råkar vara lika på Zen som den är på Firestorm/Avalanche. Rapporten skriver detta

"However, if future Apple CPUs support SMT and keep the split scheduler design, they might also be affected."

En "trevlig" egenskap med alla sårbarheten av denna typ är att de rimligen blir totalt oanvändbara som attackvektor mot "vanliga" användare. Även om man kan reda ut vilken CPU-modell en vissa användare kör med blir det rätt svårt att få någon ekonomi i den typen av attacker då "vanliga" användares HW är hopplöst heterogen.

Lite värre för molntjänster, dels ser man ju CPU-modell som kund och dels finns rätt liten varians av CPU-modeller inom en viss instans-typ. Men då kvarstår "problemet" att man så hårt måste kontrollera timing.

För PoC för SQUIP skriver man

"For our proof of concept, each virtual machine has one virtual CPU (vCPU), statically assigned to one SMT thread of a shared physical core."

Även om forskarna har modeller för hur man kan åstadkomma motsvarande utan att göra ovan (som kräver att man är "root" och om man är det behövs ju inte sårbarheten då man har tillgång till motsvarande information på långt enklare sätt i det läget) ökar dessa "andra" metoder tillförlitligheten, och den är inte superhög till att börja med...

Permalänk
Medlem

Inget nytt under solen små fel och buggar kommer vi att få leva med efter det är så bråttom ut med nya produkter så dom hinner inte testa alla möjliga varianter som kan hända och ske..

Permalänk
Medlem

@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?

Permalänk
Datavetare
Skrivet av mpat:

@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!!!

Permalänk
Medlem
Skrivet av Yoshman:

Fast alla "out-of-order" designs åkte ju dit på Spectre, så det säger väl knappast så mycket om just Intels validering. D.v.s. Intel, AMD, Apple, Qualcomm, Samsung, IBM, etc åkte alla på denna!

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.

Permalänk
Datavetare
Skrivet av GuessWho:

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.

Alla Spectre/Meltown och buggar i samma klass undviks med in-order designer. Man ser det även i Apple-länken jag postade: Apple Watch är inte påverkad och den kör in-order CPU.

Problemet är att vi nu kommit till en punkt där prestanda hos in-order är så långt efter out-of-order att den förra bara är vettigt för de absolut enklaste CPU-modellerna. Både Apple och Intels "små" kärnor är out-of-order, Apple "lilla" kärna har klart bättre perf/W jämfört med Arms senaste "lilla" kärna (som fortfarande är in-order, men de flesta gissar att man går till out-of-order för den i 2023 uppdateringen).

Vad man kanske borde fundera på är om man inte kan utnyttja heterogena CPU-designer till mer än bara maximera perf/W i "all-core" fall. Varför inte stoppa in in-order kärnor utan SMT stöd + lämpliga acceleratorer för att utföra krypto-operation på t.ex? Då skulle det kunna vara OK att ha vissa typer av sårbarheter i de "vanliga" CPU-kärnorna om de ger relevant prestandavinst!

Permalänk
Medlem
Skrivet av Yoshman:

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.

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

Citat:

Apple has released security updates for macOS Sierra and El Capitan with mitigations for Meltdown.
Apple has released updates for iOS, macOS High Sierra, and Safari on Sierra and El Capitan to help defend against Spectre.
Apple Watch is unaffected by both Meltdown and Spectre.

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

Citat:

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.

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.

Citat:

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

Permalänk
Datavetare
Skrivet av mpat:

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

Permalänk
Medlem
Skrivet av GuessWho:

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.

Rätt, tror många av oss blivit fartblinda.

Ska du inte ha taligenkänning eller dylikt för din hemautomation så kan man göra mycket med en raspberry-pi eller tom en arduino. Det fanns en tid då folk satt och skrev robotstyrningar på en PDP11. En raspberry-pi-2 har i runda slängar 5000 gånger mer processorkraft och 1000 gånger mer primärminne än en PDP11.

Permalänk
Medlem
Skrivet av Yoshman:

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

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.

Citat:

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

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.

Permalänk
Medlem

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