Nel sottosistema di crittografia di Linux si prepara la rimozione del supporto zero-copy dall'interfaccia AF_ALG per i tipi di algoritmo SKCIPHER e AEAD. La modifica è già presente nell'albero di cryptodev e ci si aspetta che venga inviata nella finestra di merge Linux 7.2, che dovrebbe aprirsi a giugno. Questa decisione è stata presa in seguito a crescenti preoccupazioni sulla sicurezza dei meccanismi zero-copy nel kernel, soprattutto dopo recenti vulnerabilità nel codice crittografico di Linux.
AF_ALG è interfaccia utente per l'API crittografica del kernel di Linux. Attraverso di essa, i programmi possono accedere alle implementazioni di cifrature, hash e algoritmi AEAD nel kernel come se fossero socket. La documentazione di Linux descrive separatamente per AF_ALG la modalità zero-copy tramite splice() e vmsplice(), in cui il kernel cerca di evitare copie non necessarie dei dati nella memoria del kernel.
Il problema è che nel caso di AF_ALG questo guadagno di prestazioni si è rivelato non così significativo, mentre i rischi sono troppo elevati. L'autore della modifica, lo sviluppatore del sottosistema crittografico di Linux Eric Biggers di Google, ha indicato, afferma che zero-copy consente allo spazio utente di eseguire operazioni crittografiche direttamente sulle pagine della cache dei file, come il binario su, e crea anche condizioni per vulnerabilità TOCTOU, quando la memoria può cambiare contemporaneamente all'operazione su di essa.
In altre parole, un meccanismo utile per l'input/output di rete o file, in AF_ALG appare come un'ottimizzazione troppo rischiosa. Lo stesso AF_ALG, secondo lo sviluppatore, viene attualmente preservato principalmente per garantire la compatibilità retroattiva con un piccolo gruppo di programmi, come iwd, che non sono ancora stati migrati alla crittografia nello spazio utente. Originariamente, AF_ALG era pensato anche per accedere agli acceleratori hardware di crittografia, ma si è rivelato non troppo efficace per questo compito.
È importante notare che non si tratta di una rimozione completa di splice() o sendfile() per AF_ALG. La modifica è descritta come una "soft break" della compatibilità: il trasferimento di dati nelle richieste AF_ALG tramite splice() e sendfile() continuerà a funzionare, ma il kernel ora farà una copia interna stabile dei dati prima dell'operazione crittografica. Le prestazioni in alcuni casi possono diminuire, ma l'API utente non viene formalmente interrotta.
Si sottolinea separatamente che al momento zero-copy viene rimosso da skcipher e aead. Il supporto per il tipo hash verrà esaminato separatamente.
Il contesto della modifica è sgradevole. Alla fine di aprile è stata scoperta una vulnerabilità Copy Fail (CVE-2026-31431) in algif_aead, cioè proprio nell'interfaccia crittografica utente AF_ALG. I ricercatori hanno dimostrato che la combinazione di AF_ALG, splice() e le peculiarità dell'elaborazione AEAD consentivano a un utente non privilegiato di danneggiare la cache delle pagine, comprese le pagine associate ai binari setuid, e di ottenere un'elevazione dei privilegi a root.
L'emergere Copy Fail è stato legato all'ottimizzazione del 2017, che ha trasferito le operazioni AEAD all'elaborazione "in loco"; durante il trasferimento di un file tramite splice() in AF_ALG, il kernel non lavorava con una copia, ma con riferimenti alle pagine della cache. Di conseguenza, parte dei dati, considerati solo di input, poteva finire nel scatterlist scrivibile.
L'eliminazione dello zero-copy da AF_ALG non è una correzione puntuale di una sola vulnerabilità. Piuttosto, è un tentativo di rimuovere un'intera classe di scenari rischiosi da un UAPI poco utilizzato, dove il guadagno dall'ottimizzazione non giustifica la complessità e le potenziali conseguenze. Per gli utenti normali, la modifica probabilmente rimarrà inosservata; per i rari programmi che utilizzano attivamente AF_ALG tramite splice() o sendfile(), è possibile un calo delle prestazioni a causa della copia aggiuntiva.
Fonte: linux.org.ru
