Linux AF_ALG Crypto Code Removing Zero-Copy Support Out Of Security Concerns
([Linux Security] 4 Hours Ago
Zero-Copy Security)
- Reference: 0001634399
- News link: https://www.phoronix.com/news/Linux-AF-ALF-Zero-Copy-Security
- Source link:
Given all the recent Linux kernel security concerns and new bugs being discovered, the Linux cryptographic subsystem is proactively dropping zero-copy functionality from AF_ALG due to growing security concerns.
[1]Zero-copy support is great for better performance and efficiency, but in kernel space it does increase the likelihood of exploiting its semantics by malicious software. The Linux AF_ALF code for exposing the Linux kernel's cryptographic API to user-space will be removing zero-copy support from the SKCIPHER and AEAD code to reduce security risks.
Linux crypto expert Eric Biggers at Google explained with [2]this patch removing the zero-copy support:
"The zero-copy support is one of the riskiest aspects of AF_ALG. It allows userspace to request cryptographic operations directly on pagecache pages of files like the 'su' binary. It also allows userspace to concurrently modify the memory which is being operated on, a recipe for TOCTOU vulnerabilities.
While zero-copy support is more valuable in other areas of the kernel like the frequently used networking and file I/O code, it has far less value in AF_ALG, which is a niche UAPI. AF_ALG primarily just exists for backwards compatibility with a small set of userspace programs such as 'iwd' that haven't yet been fixed to use userspace crypto code.
Originally AF_ALG was intended to be used to access hardware crypto accelerators. However, it isn't an efficient interface for that anyway, and it turned out to be rarely used in this way in practice.
Thus, the risks of the zero-copy support in AF_ALG vastly outweigh its benefits. Let's just remove it.
This commit removes it from the "skcipher" and "aead" algorithm types. "hash" will be handled separately.
This is a soft break, not a hard break. Even after this commit, it still works to use splice() or sendfile() to transfer data to an AF_ALG request socket from a pipe or any file, respectively. What changes is just that the kernel now makes an internal, stable copy of the data before doing the crypto operation. So performance is slightly reduced, but the UAPI isn't broken. And, very importantly, it's much safer."
With this removal patch now in the "cryptodev" Git code, expect it to be submitted for the Linux 7.2 merge window happening in June.
[1] https://www.phoronix.com/search/zero-copy
[2] https://git.kernel.org/pub/scm/linux/kernel/git/herbert/cryptodev-2.6.git/commit/?id=ffdd2bc378953b525aca61902534e753f1f8e734
[1]Zero-copy support is great for better performance and efficiency, but in kernel space it does increase the likelihood of exploiting its semantics by malicious software. The Linux AF_ALF code for exposing the Linux kernel's cryptographic API to user-space will be removing zero-copy support from the SKCIPHER and AEAD code to reduce security risks.
Linux crypto expert Eric Biggers at Google explained with [2]this patch removing the zero-copy support:
"The zero-copy support is one of the riskiest aspects of AF_ALG. It allows userspace to request cryptographic operations directly on pagecache pages of files like the 'su' binary. It also allows userspace to concurrently modify the memory which is being operated on, a recipe for TOCTOU vulnerabilities.
While zero-copy support is more valuable in other areas of the kernel like the frequently used networking and file I/O code, it has far less value in AF_ALG, which is a niche UAPI. AF_ALG primarily just exists for backwards compatibility with a small set of userspace programs such as 'iwd' that haven't yet been fixed to use userspace crypto code.
Originally AF_ALG was intended to be used to access hardware crypto accelerators. However, it isn't an efficient interface for that anyway, and it turned out to be rarely used in this way in practice.
Thus, the risks of the zero-copy support in AF_ALG vastly outweigh its benefits. Let's just remove it.
This commit removes it from the "skcipher" and "aead" algorithm types. "hash" will be handled separately.
This is a soft break, not a hard break. Even after this commit, it still works to use splice() or sendfile() to transfer data to an AF_ALG request socket from a pipe or any file, respectively. What changes is just that the kernel now makes an internal, stable copy of the data before doing the crypto operation. So performance is slightly reduced, but the UAPI isn't broken. And, very importantly, it's much safer."
With this removal patch now in the "cryptodev" Git code, expect it to be submitted for the Linux 7.2 merge window happening in June.
[1] https://www.phoronix.com/search/zero-copy
[2] https://git.kernel.org/pub/scm/linux/kernel/git/herbert/cryptodev-2.6.git/commit/?id=ffdd2bc378953b525aca61902534e753f1f8e734