În subsistemul de criptografie Linux se pregătește eliminarea suportului zero-copy din interfață AF_ALG pentru tipuri de algoritmi SKCIPHER și AEAD. Modificarea se află deja în arbori cryptodev și se așteaptă să fie trimisă în fereastra de fuziune Linux 7.2, care ar trebui să se deschidă în iunie. Motivul este creșterea preocupărilor legate de securitatea mecanismelor zero-copy în kernel, în special după recentele vulnerabilități din codul criptografic Linux.
AF_ALG — acesta este interfața utilizatorului la API-ul criptografic al kernel-ului Linux. Prin intermediul acestuia, programele pot accesa implementările de criptare, hash-uri și algoritmi AEAD din kernel ca pe socket-uri. Documentația Linux descrie separat pentru AF_ALG modul zero-copy prin splice() și vmsplice(), în care kernel-ul încearcă să evite copierea inutilă a datelor în memoria kernel-ului.
Problema este că, în cazul AF_ALG, acest câștig de performanță s-a dovedit a fi mai puțin semnificativ, iar riscurile sunt prea mari. Autorul modificării, dezvoltatorul subsistemului criptografic Linux Eric Biggers de la Google, am indicat, afirmă că zero-copy permite utilizării spațiului utilizatorului să efectueze operații criptografice direct pe paginile cache-ului de pagină al fișierelor, de exemplu binarului su, și creează condiții pentru vulnerabilitățile TOCTOU, când memoria poate fi modificată simultan cu operația deasupra ei.
Cu alte cuvinte, mecanismul, util în intrările ieșire de rețea sau fișier, în AF_ALG pare a fi o optimizare prea periculoasă. AF_ALG, conform dezvoltatorului, este păstrat în principal pentru compatibilitate înapoi cu un set restrâns de programe, cum ar fi iwd, care nu au fost încă migrate la criptografia în spațiul utilizatorului. AF_ALG a fost gândit inițial și pentru accesul la acceleratoare criptografice hardware, dar s-a dovedit a fi un interface nu foarte eficient pentru această sarcină.
Este important de menționat că nu se discută despre eliminarea completă a splice() sau sendfile() pentru AF_ALG. Modificarea este descrisă ca o "defecțiune moale" a compatibilității: transmiterea datelor în cererile AF_ALG prin splice() și sendfile() va continua să funcționeze, dar kernel-ul va face acum o copie stabilă internă a datelor înainte de operația criptografică. Performanța în unele cazuri poate scădea, dar API-ul utilizatorului nu este formal afectat.
Se subliniază separat că, deocamdată, zero-copy este eliminat din skcipher și aead. Suportul pentru tipul hash va fi discutat separat.
Contextul modificării este neplăcut. La sfârșitul lunii aprilie a fost descoperită o vulnerabilitate Copy Fail (CVE-2026-31431) în algif_aead, adică tocmai în interfața de criptare pentru utilizatori AF_ALG. Cercetătorii au arătat că legătura AF_ALG, splice() și particularitățile procesării AEAD permiteau unui utilizator fără privilegii să corupă cache-ul paginilor, inclusiv paginile asociate binarelor setuid, și să obțină creșterea privilegiilor până la root.
Apariția Copy Fail a fost asociată cu optimizarea din 2017, care a transformat operațiile AEAD în procesare „în loc”. La transmiterea fișierului prin splice() în AF_ALG, nucleul lucra nu cu o copie, ci cu referințe la paginile din cache. Ca rezultat, o parte din datele considerate doar ca intrări putea apărea în scatterlist-ul scris.
Eliminarea zero-copy din AF_ALG nu este o corectare punctuală a unei singure vulnerabilități. Mai degrabă, este o încercare de a elimina o întreagă clasă de scenarii riscante dintr-un UAPI slab utilizat, unde câștigul din optimizare nu justifică complexitatea și consecințele potențiale. Pentru utilizatorii obișnuiți, modificarea va rămâne cel mai probabil invizibilă; pentru programele rare care folosesc activ AF_ALG prin splice() sau sendfile(), s-ar putea să apară o scădere a performanței din cauza copierii suplimentare.
Sursa: linux.org.ru
