For nogle dage siden her i bloggen talte vi om LVI, der er klassificeret som en ny række angreb der kun påvirker Intel CPU'er og er karakteriseret ved at være en sekvens af angreb, der er baseret på manipulationer med de samme mikroarkitektoniske strukturer som i MDS, Spectre og Meltdown angreb.
Den største forskel mellem Jeg angriber dems LVI og MDS er, at MDS manipulerer bestemmelse af indhold af mikroarkitektoniske strukturer, der forbliver i cachen efter spekulativ fejlhåndtering eller indlæsnings- og lageroperationer mens Angrebene LVI tillader, at angriberen erstattes i mikroarkitektoniske strukturer at påvirke efterfølgende spekulativ udførelse af ofrets kode.
Selvom Intel nævner, at det arbejder på en løsning Til dette nævner de, at denne fiasko har store vanskeligheder med at være i stand til at gennemføre processen med succes, hvorfor de mener, at flere krav skal opfyldes for at få succes i det, og det er det, der har svigtet med ekstreme vanskeligheder. .
Endvidere Zola broer (en Google-udvikler) arbejdede på problemet og tilbød for nylig en programrettelse til LLVM-kompilatoren med SESES-beskyttelse (Speculative Execution Side Effects Suppression) -beskyttelse, der hjælper med at blokere angreb på specifikke spekulative eksekveringsmotorer, der påvirker Intel-CPU'er såsom LVI'er.
Den foreslåede beskyttelsesmetode implementeres på compiler-niveau og er baseret på tilføjelsen af LFENCE-udsagn af kompilatoren, når der genereres maskinkoden, som indsættes før hver læse- eller skriveinstruktion i hukommelsen, såvel som før den første greninstruktion i den instruktionsgruppe, der udfyldes i blokken.
Afbødning består af et kompileringstrin, der indsætter en LFENCE før
hver hukommelse læse instruktion, hukommelse skrive instruktion og den første
filialerklæring om en gruppe af terminatorer i slutningen af en
grundlæggende blok.
LFENCE-instruktionen forventer at bekræfte alle tidligere aflæsninger fra hukommelsen og tillader ikke proaktiv udførelse af instruktioner, der følger LFENCE inden bekræftelsen er gennemført.
Brug af LFENCE fører til et markant fald i ydeevne, Dermed, det foreslås at bruge beskyttelse i ekstreme tilfælde til især kritiske koder. Ud over fuld beskyttelse tilbyder patch'en tre flag, der selektivt deaktiverer visse beskyttelsesniveauer for at reducere den negative indvirkning på ydeevnen.
I vores test førte brugen af SESES-beskyttelse til BoringSSL-pakken til et 14 gange fald i antallet af operationer udført af biblioteket pr. Sekund: ydeevnen for biblioteksversionen samlet med beskyttelse viste sig i gennemsnit kun at være 7.1% ydeevne for den ubeskyttede version (udvidet afhængigt af testen fra 4% til 23%)
Ud over den fulde version af afbødningen implementerer denne patch tre flag for at deaktivere en del af afbødningen.
Disse flag er som standard deaktiveret. Flagene er ikke beregnet til at resultere i en sikker variant af afbødning. Indikatorerne er beregnet til at blive brugt af brugere, der ønsker at eksperimentere for at forbedre ydeevnen
afbødning.
Til sammenligning, den mekanisme, der tidligere er foreslået for GNU Assembler, der udfører LFENCE-erstatning efter hver belastning fra hukommelsen og før nogle forgreningsinstruktioner, viste et fald i ydeevne på ca. 5 gange (22% af koden uden beskyttelse).
Beskyttelsesmetoden også er blevet foreslået og implementeret af Intel-ingeniører, men resultaterne af præstationstestene er endnu ikke frigivet. Oprindeligt forudsagde forskere, der opdagede et LVI-angreb, et fald på 2-19 gange i ydelse, når de anvendte fuld beskyttelse.
Endelig, hvis du vil vide mere om det, kan du kontrollere detaljerne I det følgende link.