Hertzbleed utnyttjar turbofrekvenser för att komma åt information

Lösning: skaffa en Celeron som inte har turbo.

Eller så borde det vara vara att stänga av turbo och sätta att den ska ligga konstant på en nivå tex en Alla kärnor OC med C step avstängt. Men tror inte vanligt folk behöver oroa sig.

Jo precis en av lösningarna som föreslogs där är just att stänga av turbo.

Känns väldigt hypotetiskt då ett OS som Windows eller Linux alltid har en massa olika processer igång i bakgrunden som hela tiden varierar med någon tiondels procent i last så man kan inte mäta exakt hur länge en viss operation tar i isolation. Processer kan också hoppa mellan kärnor, det kan ske cache misses o.s.v. Lägg till det t.ex. att fläktar varvar upp olika snabbt på olika system, olika exemplar av samma CPU kan ha marginellt olika boost-beteende, och att t.o.m. rumstemperaturen påverkar boostfrekvensen (har "förlorat" 25 MHz nu jämfört med i vintras). Alla vet ju att man måste köra benchmarks flera gånger i följd för att få ett pålitligt medelvärde eftersom en enskild körning kan variera i prestanda med några procent.

Säg inte det, just det här med att kryptografiska implementationer behöver göra arbetet på konstant tid för att inte läcka information är ju etablerat sedan gammalt, det är inte något som bara avfärdas trots att koden i regel körs i den typ av "brusiga" miljö du beskriver.
Detta är ju i princip ett specialfall där även en korrekt implementation, som sett till antalet klockcykler som förbrukas gör arbetet på konstant tid, till följd av hårdvarans turbobeteende ändå tar varierande tid att göra jobbet, och detta dessutom på ett sätt där den varierande tiden beror på indatan.

Trivialt att utnyttja på försöka försöket varje gång? Säkerligen inte.
Omöjligt att utnyttja i verkligheten? Förmodligen inte.

Detta är ju dock inte fallet här. Det möjligt att utveckla attacker som använder denna teknik som funkar över Internet, givet rätt omständigheter.

Inga antenner krävs, vet inte var du fått detta från.

Finns det några tester för hur mycket prestanda man förlorat med alla dessa "fixar" genom åren för säkerhetshål och dylikt? Sitter på en intel 9600k

Skydda åtkomsten till burkarna så är det fine. Dvs se till att de som potentiellt kan utnyttja sårbarheten inte kommer åt hårdvaran (vilket de inte heller ska). Annars så får man stänga av turbofunktionen men det känns som en "dum" lösning.

Vet inte om jag missförstår dig här, men svagheten här är inte att klockfrekvensen ändras om man har fler eller färre kärnor aktiva - svagheten är att effektförbrukningen på en kärna ändras av vilken data den arbetar med. Enkelt uttryckt - om det är många binära ettor i den övre delen av ett tal, drar det mer ström än om det är många nollor. Eftersom högre effektförbrukning leder till att klockfrekvensen går ner, kan man genom att mäta tiden detektera vilka tal algoritmen jobbar med. Forskarna har sedan konstruerat ett fall där algoritmen jobbar med talet 0 om en viss bit är samma som den föregående, och använder sedan en mätning av den förbrukade tiden till att detektera om detta inträffar.

För att denna metod skall fungera på något annat än Intels chip, krävs det att de har samma typer av optimeringar, där man spar ström om många av de övre bitarna i ett tal är 0. Det är inte alls säkert att Apples chip har det. Det är inte omöjligt, men långt ifrån givet.

Slutligen: attacken i det här fallet tog 36 timmar i det bästa fallet, och en attack mot en liknande men inte identisk setup tog 89 timmar, eller nästan 4 dagar. Även om den säkert går att optimera, bör det också gå att göra den svårare genom att uppdatera algoritmer. Om det skiljer en faktor 2.5 mellan två liknande implementationer, finns det en del att hämta här. Man bör också kunna bygga system som försöker detektera hacker-försök som pågår i flera dagar.

Eh. Detta är inte Spectre. Detta är en teoretisk attack, som möjligen kan bli en byggsten i något värre, men det är ingen kris än.

Rapporten visar på ett exempel där angreppet genomfördes över Internet, så nej, det räcker inte. Som jag skrev ovan är jag inte speciellt orolig, men just detta var inget bra argument.

Så förstod även jag det, d.v.s. ett krav är att CPU-frekvensen på något sätt har ett beroende av strömförbrukning. I det läget blir bl.a. Apples CPUer opåverkade då de inte har ett sådant beroende mellan last och frekvens. Det är samma frekvens vare sig man kör skalär-addition, vektor-operationer, etc, det på en eller alla kärnor.

Om det är så att man kan omöjliggöra denna attack genom att fixera frekvensen och om attacken faktiskt är praktisk användbar känns ju den rimligast fixen framåt att utföra den här typen av operationer på en hjälpkrets. När kryptering är involverad befinner man sig rätt sällan i den mest prestandakritiska delen, så högre latens (vilket tyvärr lär bli effekten av att lägga operationen på en extern krets) är ett litet problem.

Fast både Intel och AMD verkar tycka att sårbarheten är allt för opraktisk att utnyttja utanför labbmiljö för att det ska en vara värt att fixa problemet. Gissar att de har något på fötterna kring detta, men är absolut inte 100 %-ig garanti....

Så om man kör allcore OC med satt frekvens så är det inte något problem? Vissa överklockare är immuna?

Spännande om en praktisk mitigering faktiskt *ökar* prestanda den här gången.

Ah, OK, då fattar jag.

Det där med en separat krets slog mig också. Den behöver inte ens vara så speciellt separat, bara den har en fixerad klockfrekvens så länge den är aktiv. Tillverkarna lägger ju transistorer på allehanda grejer som sällan används, medan kryptering körs av alla varenda dag.