I subsystems för kryptografi i Linux förbereds borttagning av stöd zero-copy frĂ„n grĂ€nssnittet AF_ALG för typ av algoritmer SKCIPHER och AEAD. Ăndringen finns redan i cryptodev-trĂ€det och vĂ€ntas skickas för sammanslagning Linux 7.2, som bör öppna i juni. Anledningen Ă€r vĂ€xande farhĂ„gor kring sĂ€kerheten hos zero-copy-mekanismer i kĂ€rnan, sĂ€rskilt efter nyligen upptĂ€ckta sĂ„rbarheter i Linux kryptografikod.
AF_ALG â detta Ă€r anvĂ€ndargrĂ€nssnittet till Linux kĂ€rnans kryptografiska API. Genom det kan program fĂ„ tillgĂ„ng till implementationer av chiffer, hashfunktioner och AEAD-algoritmer i kĂ€rnan som sockets. Linux-dokumentationen beskriver separat zero-copy-lĂ€ge för AF_ALG genom splice() och vmsplice(), dĂ€r kĂ€rnan strĂ€var efter att undvika onödig kopiering av data till kĂ€rnminnet.
Problemet Àr att den prestandavinsten för AF_ALG visade sig vara mindre viktig, medan riskerna Àr för stora. Författaren till förÀndringen, utvecklaren av Linux kryptografiska subsystem Eric Biggers frÄn Google, att, pÄpekar att zero-copy tillÄter anvÀndarutrymmet att utföra kryptografiska operationer direkt pÄ sidorna i page cache-filer, som till exempel binÀrsu, och skapar dessutom förutsÀttningar för TOCTOU-sÄrbarheter, dÀr minnet kan Àndras samtidigt med operationen pÄ det.
Med andra ord, mekanismen som Àr anvÀndbar i nÀtverks- eller filin- och utdata, verkar i AF_ALG som en alltför farlig optimering. Enligt utvecklaren bevaras AF_ALG i huvudsak för bakÄtkompatibilitet med ett litet antal program, som iwd, som Ànnu inte har övergÄtt till kryptografi i anvÀndaruprymmet. Ursprunligen var AF_ALG avsedd för att ge Ätkomst till hÄrdvarukryptoprocessorer, men visade sig i praktiken vara ett ineffektivt grÀnssnitt för denna uppgift.
Det Ă€r viktigt att notera att det inte handlar om att helt ta bort splice() eller sendfile() frĂ„n AF_ALG. Ăndringen beskrivs som en "mjukt brott" av kompatibilitet: överföring av data till AF_ALG-förfrĂ„gningar via splice() och sendfile() kommer fortsatt att fungera, men kĂ€rnan kommer nu att göra en intern stabil kopia av data innan kryptografisk operation. Prestanda kan i vissa fall minska, men anvĂ€ndarens API bryts inte formellt.
Det pÄpekas ocksÄ sÀrskilt att zero-copy tas bort frÄn skcipher och aead. Stöd för typen hash kommer att övervÀgas separat.
Kontexten för förÀndringen Àr obehaglig. I slutet av april avslöjades en sÄrbarhet Copy Fail (CVE-2026-31431) i algif_aead, det vill sÀga just i anvÀndarens kryptointerface AF_ALG. Forskare har visat att kombinationen av AF_ALG, splice() och egenskaperna hos AEAD-behandling gjorde det möjligt för icke-privilegerade anvÀndare att skada page cache, inklusive sidor som motsvarade setuid-binÀrer, och att fÄ en förhöjning av privilegier till root.
Uppkomsten Copy Fail var kopplad till optimeringen frÄn 2017 som överförde AEAD-operationer till «in-place» behandling; nÀr en fil överfördes via splice() i AF_ALG arbetade kÀrnan inte med en kopia utan med referenser till sidor i page cache. Som ett resultat kunde en del av de data som ansÄgs vara endast ingÄngar hamna i den skrivbara scatterlistan.
Borttagandet av zero-copy frÄn AF_ALG Àr inte en punktlös ÄtgÀrd för en enda sÄrbarhet. Snarare Àr det ett försök att ta bort en hel klass av riskabla scenarier frÄn det sÀllan anvÀnda UAPI, dÀr vinsten frÄn optimering inte motiverar komplexiteten och potentiella konsekvenser. För vanliga anvÀndare kommer förÀndringen sannolikt att förbli osynlig; för sÀllsynta program som aktivt anvÀnder AF_ALG genom splice() eller sendfile() kan det bli en prestandaförlust pÄ grund av ytterligare kopiering.
KĂ€lla: linux.org.ru
