I går publiserte vi her på bloggen nyheten om Aya, et bibliotek for å lage eBPF-drivere i Rust og er at formålet med dette er å skape sikrere drivere eller Prossimo-prosjekt for å sikre minne av Linux-kjernen med Rust (to flotte prosjekter som vil ha mye å snakke om de neste månedene).
Og det I løpet av kort tid er det rapportert om ulike sårbarheter der dra nytte av feil i eBPF og at det er et problem der kerneutviklerne ikke har sluttet å jobbe og kanskje Rust er løsningen.
Årsaken til å berøre dette emnet er at nylig ble nyheten utgitt som de har identifisert "Annet" sårbarhet i Linux-kjernen (CVE-2021-33624) for omgå beskyttelse mot Spectre-klassen sårbarheter, siden dette tillater bruk av eBPF-delsystemet for å kunne bestemme innholdet i minnet som et resultat av opprettelsen av betingelser for spekulasjoner om utførelse av visse operasjoner.
Det nevnes at sårbarheten det er forårsaket av feil i verifisereren, som brukes til å oppdage feil og ugyldig aktivitet i BPF-programmer. Verifikatoren viser de mulige kjøringsbanene til koden, men ignorerer eventuelle forgreningsalternativer som ikke er gyldige sett fra semantikken til instruksjonsarkitekturen.
Når du kjører et BPF-program, kan forgreningsalternativer som ikke ble tatt i betraktning av verifisereren, forutsies feil av prosessoren og utføres i en spekulativ modus.
På berørte systemer kan et uprivilegert BPF-program utnytte dette sikkerhetsproblemet for å filtrere innholdet i vilkårlig kjerneminne (og dermed alt fysisk minne) gjennom en sidekanal.
Eg når man analyserer "last" -operasjonen, antar verifisereren at instruksjonen bruker et register med en adresse hvis verdi alltid er innenfor de angitte grensene, men en angriper kan skape forhold under hvilke prosessoren vil spekulativt forsøke å utføre en handel med en adresse som ikke oppfyller bekreftelsesbetingelsene.
Spectre-angrepet krever tilstedeværelse av et bestemt skript i den privilegerte koden, som fører til spekulativ gjennomføring av instruksjoner. Ved å manipulere BPF-programmene som sendes for utføring, er det mulig å generere slike instruksjoner i eBPF og filtrere innholdet i kjerneminne og vilkårlige områder av fysisk minne gjennom sidekanaler.
Videre du kan merke et notat om ytelsespåvirkningen av eiendeler for å beskytte mot Spectre-klassen av sårbarheter.
Dette notatet oppsummerer resultatene rr (Record and Replay) debugger optimalisering, en gang opprettet av Mozilla for å feilsøke vanskelige å gjenta feil i Firefox. Caching av systemanropene som ble brukt for å verifisere eksistensen av kataloger, reduserte "rr sources" -operasjonen for testprosjektet fra 3 minutter 19 sekunder til 36 sekunder.
Optimaliseringsforfatteren bestemte seg for å sjekke hvor mye vil endre seg ytelse etter deaktivering av Spectre-beskyttelse. Etter oppstart av systemet med parameteren "mitigations = off", var utførelsestiden for "rr sources" uten optimalisering 2 minutter 5 sekunder (1.6 ganger raskere) og med optimalisering 33 sekunder (9% raskere).
Merkelig nok deaktivere Spectre-beskyttelse ikke bare redusert kjøretid av kärnenivåkoden på 1.4 ganger (fra 2 min 9s til 1 min 32s), det halverte også utførelsestiden i brukerområdet (fra 1 min 9s til 33s), antagelig på grunn av en reduksjon i effektiviteten CPU-cache og TLB tilbakestilles når Spectre-beskyttelse er aktivert.
Problemet har dukket opp siden 4.15-kjerneutgivelsen og har blitt fikset i form av lapper, som på dette tidspunktet fremdeles ikke når alle distribusjoner, så det anbefales at brukerne i disse dager gjør de aktuelle oppdateringene så snart de mottar varslene.
Si du vil vite mer om det, kan du sjekke detaljene I den følgende lenken.