Në nën-sistemin e kriptografisë Linux po përgatitet heqja e mbështetjes zero-copy nga ndërfaqja AF_ALG për llojet e algoritmeve SKCIPHER dhe AEAD. Ndryshimi tashmë është në pemën cryptodev dhe pritet të dërgohet në dritaren e bashkimit Linux 7.2, e cila duhet të hapet në qershor. Shkaku janë shqetësimet në rritje mbi sigurinë e mekanizmave zero-copy në bërthamë, veçanërisht pas dobësive të fundit në kodin kriptografik të Linux.
AF_ALG â kjo Ă«shtĂ« ndĂ«rfaqja pĂ«rdoruesi nĂ« API-nĂ« kriptografike tĂ« bĂ«rthamĂ«s Linux. PĂ«rmes saj, programet mund tĂ« aksesojnĂ« implementimet e shifrave, hash-eve dhe algoritmeve AEAD nĂ« bĂ«rthamĂ« si sokete. Dokumentacioni i Linux pĂ«rshkruan veçmas pĂ«r AF_ALG modalitetin zero-copy pĂ«rmes splice() dhe vmsplice(), ku bĂ«rthama pĂ«rpiqet tĂ« shmangĂ« kopjimin e tepĂ«rt tĂ« tĂ« dhĂ«nave nĂ« memorjen e bĂ«rthamĂ«s.
Problemi është se, në rastin e AF_ALG, përfitimi i tillë në performancë nuk doli të ishte aq i rëndësishëm, kurse rreziqet janë shumë të mëdha. Autori i ndryshimit, zhvilluesi i nën-sistemit kriptografik të Linux, Erik Biggers nga Google, caktova, që zero-copy i lejon hapësirës së përdoruesit të ekzekutojë operacione kriptografike drejtpërdrejt mbi faqet e cache të skedarëve, për shembull binarin su, dhe gjithashtu krijon kushte për dobësitë TOCTOU, kur memorie mund të ndryshohet në të njëjtën kohë me operacionin mbi të.
Në fjalë të tjera, mekanizmi, i dobishëm për hyrjen dhe daljen në rrjet ose skedar, në AF_ALG duket si një optimizim shumë të rrezikshëm. Vetë AF_ALG, sipas zhvilluesit, tani ruhet kryesisht për shkak të përputhshmërisë së prapambetur me një grup të vogël programesh, për shembull iwd, të cilat ende nuk janë përkthyer në kriptografi në hapësirën e përdoruesit. Fillimisht AF_ALG ishte menduar edhe për qasje në akceleratorët kriptografikë të harduerit, por në praktikë u tregua se nuk ishte një ndërfaqe shumë efektive për këtë detyrë.
ĂshtĂ« e rĂ«ndĂ«sishme tĂ« theksohet se nuk po flasim pĂ«r njĂ« eleminim tĂ« plotĂ« tĂ« splice() ose sendfile() pĂ«r AF_ALG. Ndryshimi pĂ«rshkruhet si njĂ« "prishje e butĂ«" e kompatibilitetit: transmetimi i tĂ« dhĂ«nave nĂ« kĂ«rkesat AF_ALG pĂ«rmes splice() dhe sendfile() do tĂ« vazhdojĂ« tĂ« funksionojĂ«, por bĂ«rthama tani do tĂ« bĂ«jĂ« njĂ« kopje stabile tĂ« brendshme tĂ« tĂ« dhĂ«nave para operacionit kriptografik. Performanca nĂ« disa raste mund tĂ« zvogĂ«lohet, por API i pĂ«rdoruesit formalisht nuk prishĂ«t.
Veçanërisht theksohet se për momentin zero-copy po hiqet nga skcipher dhe aead. Mbështetja për llojin hash do të shqyrtohet veçmas.
Konteksti për këtë ndryshim është i pakëndshëm. Në fund të prillit u zbulua një vulnerabilitet Copy Fail (CVE-2026-31431) në algif_aead, pra në ndërfaqen kriptografike të përdoruesit AF_ALG. Studiuesit treguan se lidhja AF_ALG, splice() dhe veçoritë e përpunimit AEAD lejonin një përdorues pa privilegje të dëmtonte page cache, përfshirë faqet që i përkisnin binarëve setuid, dhe të merrte përmirësim privilegjesh deri në root.
Shfaqja Copy Fail ishe lidhur me optimizimin e vitit 2017, i cili e transferoi operacionin AEAD për përpunim "në vend"; kur dërgohet një file përmes splice() në AF_ALG, bërthama punonte jo me një kopje, por me referenca në faqet e caches. Si rezultat, një pjesë e të dhënave, të cilat konsideroheshin si input vetëm, mund të përfundonin në scatterlist të shkruara.
Heqja e zero-copy nga AF_ALG nuk është një rregullim i veçantë për vetëm një vulnerabilitet. Në vend të kësaj, kjo është një përpjekje për të eliminuar një klasë të tërë skenarësh të rrezikshëm nga UAPI i pakëtuar, ku përfitimi nga optimizimi nuk justifikon kompleksitetin dhe pasojat potenciale. Për përdoruesit e zakonshëm, ndryshimi do të mbetet ndoshta i padukshëm; për programet e rralla që përdorin aktivisht AF_ALG përmes splice() ose sendfile(), mund të ketë një humbje të performancës për shkak të kopjimit shtesë.
Burimi: linux.org.ru
