В подсистемата за криптография на Linux се подготвя премахване на поддръжката zero-copy от интерфейса AF_ALG за типове алгоритми SKCIPHER и AEAD. Промените вече са в дървото cryptodev и се очаква да бъдат изпратени в прозорец за сливане Linux 7.2, който трябва да се отвори през юни. Причината са нарастващите притеснения относно безопасността на zero-copy механизмите в ядрото, особено след наскоро откритите уязвимости в криптографския код на Linux.
AF_ALG — това е потребителския интерфейс к криптографския API на ядрото на Linux. Чрез него програмите могат да се обръщат към реализации на шифри, хешове и AEAD алгоритми в ядрото като към сокети. Документацията на Linux отделно описва за AF_ALG режима zero-copy чрез splice() и vmsplice(), при който ядрото се опитва да избегне излишното копиране на данни в паметта на ядрото.
Проблемът е, че в случая с AF_ALG това предимство в производителността не е толкова важно, а рисковете са прекалено големи. Авторът на промяната, разработчикът на криптографската подсистема на Linux, Ерик Биггерс от Google, посочи, че zero-copy позволява на потребителското пространство да изпълнява криптографски операции директно върху страниците на page cache файлове, например бинарника su, а също така създава условия за уязвимости TOCTOU, когато паметта може да се променя едновременно с операцията върху нея.
С други думи, механизмът, полезен в мрежовия или файловия вход-изход, в AF_ALG изглежда като твърде опасна оптимизация. Самият AF_ALG, според разработчика, в момента основно се запазва заради обратна съвместимост с малък набор от програми, например iwd, които все още не са преминали на криптография в потребителското пространство. Първоначално AF_ALG е проектиран и за достъп до хардуерни криптоускорители, но на практика се е оказал не особено ефективен интерфейс за тази задача.
Важно е да се подчертае, че не става въпрос за пълно премахване на splice() или sendfile() за AF_ALG. Промените се описват като "меко счупване" на съвместимостта: предаването на данни в AF_ALG заявки чрез splice() и sendfile() ще продължи да работи, но ядрото сега ще прави вътрешна стабилна копия на данните преди криптографската операция. Производителността в някои случаи може да намалее, но потребителското API формално няма да бъде нарушено.
Отделно се подчертава, че в момента zero-copy се премахва от skcipher и aead. Поддръжката за типа hash ще бъде разгледана отделно.
Контекстът на промените е неприятен. В края на април беше разкрита уязвимост Copy Fail (CVE-2026-31431) в algif_aead, тоест точно в потребителския криптоинтерфейс AF_ALG. Изследователите показаха, че комбинацията от AF_ALG, splice() и особеностите на AEAD-обработката позволява на непривилегирован потребител да повреди кеша на страницата, включително страниците, свързани със setuid-бинарници, и да получи повишаване на привилегиите до root.
Появата Copy Fail беше свързана с оптимизация от 2017 година, която премести AEAD-операциите в обработка „на място“; при предаване на файл чрез splice() в AF_ALG ядрото работеше не с копие, а със ссылки на страниците в кеша. В резултат част от данните, които бяха считани само за входящи, можеше да се окажат в записвания scatterlist.
Премахването на zero-copy от AF_ALG не е самоцелно решение на една уязвимост. По-скоро това е опит да се премахне цял клас рискови сценарии от малко използвания UAPI, където печалбата от оптимизация не оправдава сложността и потенциалните последствия. За обикновените потребители промяната вероятно ще остане незабелязана; за редки програми, които активно използват AF_ALG чрез splice() или sendfile(), е възможна загуба на производителност поради допълнителното копиране.
Източник: linux.org.ru
