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