W podsystemie kryptografii Linux przygotowywane jest usunięcie wsparcia zero-copy z interfejsu AF_ALG dla typów algorytmów SKCIPHER i AEAD. Zmiana znajduje się już w drzewie cryptodev i oczekuje na przesłanie w oknie scalania Linux 7.2, które powinno otworzyć się w czerwcu. Powodem są rosnące obawy dotyczące bezpieczeństwa mechanizmów zero-copy w jądrze, szczególnie po niedawnych podatnościach w kodzie kryptograficznym Linuxa.
AF_ALG — to interfejs użytkownika do kryptograficznego API jądra Linux. Dzięki niemu programy mogą uzyskiwać dostęp do implementacji szyfrów, haszy i algorytmów AEAD w jądrze jak do gniazd. Dokumentacja Linuxa oddzielnie opisuje tryb zero-copy dla AF_ALG za pomocą splice() i vmsplice(), w którym jądro stara się unikać niepotrzebnego kopiowania danych do pamięci jądra.
Problem w tym, że w przypadku AF_ALG takie zyski wydajności okazały się niewystarczające, a ryzyka zbyt duże. Autor zmiany, programista kryptograficznej podsystemu Linux, Erik Biggers z Google, zaznaczył, że zero-copy pozwala przestrzeni użytkownika na przeprowadzanie operacji kryptograficznych bezpośrednio na stronach pamięci podręcznej stron plików, na przykład binarnego pliku su, co tworzy warunki dla podatności TOCTOU, gdy pamięć może być zmieniana w trakcie operacji na niej.
Innymi słowy, mechanizm użyteczny w sieciowym lub plikowym wejściu-wyjściu w AF_ALG wydaje się zbyt niebezpieczną optymalizacją. Sam AF_ALG, według słów programisty, jest obecnie głównie utrzymywany dla wstecznej kompatybilności z niewielką liczbą programów, takich jak iwd, które jeszcze nie zostały przekształcone do kryptografii w przestrzeni użytkownika. Początkowo AF_ALG był zaprojektowany do dostępu do sprzętowych akceleratorów kryptograficznych, ale w praktyce okazał się mało efektywnym interfejsem do tego zadania.
Ważne jest, że nie chodzi tu o całkowite usunięcie splice() lub sendfile() dla AF_ALG. Zmiana opisana jest jako "miękkie złamanie" kompatybilności: przesyłanie danych w AF_ALG przez splice() i sendfile() nadal będzie działać, ale jądro teraz będzie tworzyć wewnętrzną stabilną kopię danych przed operacją kryptograficzną. W niektórych przypadkach wydajność może się zmniejszyć, ale publiczne API formalnie nie jest łamane.
Osobno podkreśla się, że na razie zero-copy jest usuwane z skcipher i aead. Wsparcie dla typu hash będzie rozważane osobno.
Kontekst zmian jest nieprzyjemny. Pod koniec kwietnia ujawniono lukę Copy Fail (CVE-2026-31431) w algif_aead, czyli dokładnie w użytkowniczym interfejsie kryptograficznym AF_ALG. Badacze pokazali, że kombinacja AF_ALG, splice() i cech przetwarzania AEAD umożliwiała nieuprzywilejowanemu użytkownikowi uszkodzenie pamięci podręcznej strony, w tym stron odpowiadających binarkom setuid, i zdobycie podwyższonych uprawnień do roota.
Pojawienie się Copy Fail było związane z optymalizacją z 2017 roku, która przekształciła operacje AEAD na przetwarzanie 'w miejscu'; podczas przesyłania pliku przez splice() w AF_ALG jądro nie działało z kopią, ale z odniesieniami do stron pamięci podręcznej. W rezultacie część danych, które były uważane tylko za dane wejściowe, mogła znaleźć się w zapisywanej scatterlist.
Usunięcie zero-copy z AF_ALG nie jest jednolitym rozwiązaniem tylko jednej luki. Raczej jest to próba wyeliminowania całej klasy ryzykownych scenariuszy z mało używanego UAPI, gdzie zyski z optymalizacji nie uzasadniają złożoności i potencjalnych konsekwencji. Dla zwykłych użytkowników zmiana najprawdopodobniej pozostanie niezauważona; dla rzadko używanych programów, które aktywnie korzystają z AF_ALG za pomocą splice() lub sendfile(), możliwe jest obniżenie wydajności z powodu dodatkowego kopiowania.
Źródło: linux.org.ru
