Det är inte så att OSPRay rent generellt bli så mycket långsammare. I det ramverket finns ganska många mikro-benchmarks som testar specifika delar av ett typiskt betydligt större flöde.
Just de specifika momenten man testar i testerna använder uppenbarligen VGATHER* i hot-path.
Det finns garanterat verkliga fall som kommer påverkas rejält, är som sagt därför det är kritiskt att kunna stänga av fixarna (för de är helt onödig om det handlar om en rendering-maskin som står på ett LAN utan desktop).
Men i just detta fall lär knappast något "verkligt" fall med OSPray påverkas i närheten av några 50 % då en sak som "partikelvolymer" lär vara en rätt liten del av en hel scen.
Just i de fall som likt OSPRay bygger på Intels OneAPI kommer sedan problemet längre fram bli långt mindre. Det mesta här är skapat av en kompilator, det "enda" som måste till här är att man får definiera om "optimal instruktion" för de drabbade CPU-modellerna så de gör logisk samma sak utan VGATHER* (det kommer vara långsammare, men inte lika illa som en mikrokod-fixad VGATHER*).
Samma gäller Inception: det kommer säkert gå att hitta mikrobenchmarks som påverkas rätt illa. Men det kommer vara ytterst få, om något, "verklig" fall som påverkas speciellt mycket. Skulle det ändå finnas sådana fall kommer man tillbaka till: det måste gå att stänga av fixarna för i praktiken kräver dessa sårbarheter att någon okänd kan köra valfri (attack)kod på systemet.
Det läskiga potentiella attack-vektorn på "vanliga" desktop är JavaScript i webbläsaren. Det andra stora problemet är datacenter, fast i princip alla dessa problem "hanteras" genom att man alltid får varje fysisk kärna "för sig själv" och det krävs nästan alltid att man kan köra kod på samma fysiska kärna som det man vill "stjäla" information från också kör.
Skrivet av Dyluck:
Kanske bara acceptera att side channel attacker finns och inte går att åtgärda, utan fokusera på att göra resultatet av attackerna helt värdelöst genom att kryptera minnet istället, liknande Secure Encrypted Virtualization (SEV)?
Så tänkte jag också först, men insåg snabbt varför det tyvärr inte är någon snilleblixt: dessa attacker går inte via RAM, de går via register, data-cache, instruktions-cache, branch-target-buffers etc. Den information det handlar om är aldrig krypterad på den nivå, det skulle bli allt för långsamt!
Om process A jobbar mot "sitt" RAM ser den ju "sina" saker i klartext, är tyvärr just den klartexten man kommer åt om man lyckas använda dessa attacker.
Sen ska man vara medveten om att dessa attacker är ungefär som att man kan bygga världens mest dyra/komplexa lösning för att stjäla en modern bil som är "keyless". Men i praktiken är det långt enklare att ta andra vägar, i bilens fall verkar en långt populärare lösning vara att få tag i nycklarna/sändaren och i datorfallet finns betydligt enklare sårbarheter att utnyttja i OS/program (kollar man CVE:er dyker det typiskt upp ett par root-access buggar per månad i de populära OS:en).
Skrivet av KoAoL:
Nu blir det solklart. 😆
Multimedia är det enda jag plockar med mig därifrån.
Handlar det om lagring, avkodning, uppspelning eller kopiering? På nätet eller i redigerare? Som sagt denna sidan av datorn kan jag väldigt lite om men är nyfiken. Och vad skulle en lösning sänka hastigheten på? Streaming, hemsidor, Spotify eller ljud/bild i spel? Försöker sätta mig in i ett worst case scenario bara. Om man laddat ner något oförsiktigt och det räcker att något autospelas på en hemsida t.ex.
I teorin: ja!
I praktiken saknar flera av dessa sårbarheter ens fungerande proof-of-concept, när det finns proof-of-concept kräver dessa i många fall att man är root/admin för att de ska fungera (finns ju ett proof-of-conect för Inception, där verkar man köra "victim på typ alla kärnor" så man är säker att den körs där "attacker" körs, ett alternativ hade varit att köra som root och låsa "victim" till speciella kärnor).
Om det krävs root/admin är det poänglöst, då har man redan total kontroll av systemet!
Det som gjort att man är lite mer nervös över Downfall (samt Zenbleed) är att de går via AVX/AVX-512 register och dessa register används numera även i väldigt generell strängbibliotek som nästan alla applikationer använder. Positiva är att strängbiblioteken lär nog inte behöva VGATHER* givet att data i det fallet "ligger på rad" (då är VPMOV* betydligt snabbare).
