Linuxi krüptograafia alamsüsteemis valmistatakse ette tugiteenuse eemaldamist zero-copy liidesest AF_ALG algoritmi tüüpide jaoks SKCIPHER ja AEAD. Muudatus on juba cryptodevi puu sees ja ootab sulandumise aknas saatmist Linux 7.2, mis peaks avanema juunis. Põhjuseks on mure zero-copy mehhanismide turvalisuse üle kernis, eriti pärast hiljutisi haavatavusi Linuxi krüptograafilises koodis.
AF_ALG — see on kasutajaliides Linuxi krüptograafia API-le. Selle kaudu saavad programmid pöörduda krüptograafiliste algoritmide, hash’ide ja AEAD-algoritmide teostuste poole kernis nagu soketite poole. Linuxi dokumentatsioon kirjeldab eraldi AF_ALG zero-copy režiimi läbi splice() ja vmsplice(), mille käigus püüab kern vältida tarbetut andmete kopeerimist kerni mällu.
Probleem on selles, et AF_ALG puhul ei osutunud see jõudluse kasu nii märkimisväärseks ja riskid on liiga suured. Muudatuse autor, Linuxi krüptograafia alamsüsteemi arendaja Erik Biggers Google'ist, mainis, et zero-copy võimaldab kasutajaruumi käivitada krüptograafilisi toiminguid otse failide page cache'i lehtedel, näiteks binaarfailis su, ja loob tingimused TOCTOU-haavatavustele, kus mälu võib samal ajal muutuda toimingu käigus.
Teisisõnu, mehhanism, mis on kasulik võrgus või failide sisendi-väljundi puhul, näeb AF_ALG-is välja liiga ohtliku optimeerimisena. Ise AF_ALG, arendaja sõnul, säilitakse praegu peamiselt tagurpidi ühilduvuse nimel väikese programmide kogumi jaoks, näiteks iwd, mis pole veel üleviidud kasutajaruumi krüptograafiale. Alguses oli AF_ALG mõeldud ka riistvaraliste krüptokiirendite juurde pääsemiseks, kuid praktikas osutus see selle ülesande jaoks mitte eriti tõhusaks liideseks.
Oluline on märkida, et tegemist ei ole splice() või sendfile() täieliku eemaldamisega AF_ALG jaoks. Muudatus kirjeldatakse kui „pehme rike“ ühilduvuses: andmete edastamine AF_ALG päringutesse splice() ja sendfile() kaudu jätkab töötamist, kuid kern teeb nüüd krüptograafilise toimingu eel stabiilse sisemise koopia andmetest. Jõudlus võib mõnel juhul väheneda, kuid kasutaja API ei purune formaalselt.
Erinevalt rõhutatakse, et praegu eemaldatakse zero-copy skcipher ja aead. Tüübi toetamine hash arutatakse eraldi.
Muudatus toimub ebasoodsates oludes. Aprilli lõpus paljastati haavatavus Kopeeri nurjumine (CVE-2026-31431) algif_aead, mis tähendab, et see on täpselt kasutaja krüptoliidese AF_ALG osas. Uurijad näitasid, et AF_ALG, splice() ja AEAD-töötluse omaduste kombinatsioon võimaldas mitteprivilegeeritud kasutajal kahjustada page cache'i, sealhulgas lehti, mis vastavad setuid-binaaridele, ning saada juurkontrolli õiguseid.
Ilmumine Kopeeri nurjumine oli seotud 2017. aasta optimeerimisega, mis viis AEAD-operatsioonid „kohtade peal“ töötlemisse; failide edastamisel splice() kaudu AF_ALG-i, töötles kerneli mitte koopia, vaid lingid page cache'i lehtedele. Selle tulemusena võivad osa andmetest, mida peeti ainult sisenditeks, ilmuda kirjutatavas scatterlist'is.
Zero-copy eemaldamine AF_ALG-ist ei ole punktikohane parandus ainult ühe haavatavuse jaoks. Pigem on see katse kõrvaldada terve riskantsete stsenaariumite klass vähekasutatavas UAPI-s, kus optimeerimisest saadav kasu ei õigusta keerukust ja potentsiaalseid tagajärgi. Tavalistele kasutajatele jääb see muutus tõenäoliselt märkamatuks; haruldaste programmide puhul, mis kasutavad AF_ALG-i aktiivselt läbi splice() või sendfile(), võib tekkida jõudluse langus täiendava kopeerimise tõttu.
Allikas: linux.org.ru
