On 29.07.2023 10:40, Ard Biesheuvel wrote:
AF_ALG was never intended to provide a general purpose crypto library
to user space, but only to expose asynchronous hardware crypto
accelerators that are DMA based and managed by the OS.
Exposing the pure-software crypto implementations via AF_ALG was a
mistake IMHO. Making system calls into a privileged environment just
to run some algorithm that could easily run unprivileged as well is a
bad idea both for performance as well as for security/robustness. (On
top of that, SIMD based implementations need to execute with
preemption disabled, increasing scheduling jitter)
Due to the kernel's rigid 'no regressions' policy, AF_ALG will retain
support for the modes and algorithms it supports today, but I don't
think we should extend this support unless we limit it to
implementations provided by hardware accelerators. If it can be done
in software, it should be done in user space, not in the kernel.
Thank you for the detailed explanation Ard. This makes sense to me.
I did a quick lookup for hardware crypto accelerators available on the
market and, indeed, symmetric algorithms along with hashes constitute
the vast majority of what these accelerators support [0].
I've found some accelerators that support asymmetric operations but it
seems they are mostly targeted at microcontrollers and as such are
probably outside of supported area here [1][2]. (The accelerator at [0]
supports asymmetric operations but only public key ones).
[0]: https://www.rambus.com/security/crypto-accelerator-cores/
[1]:
https://www.ibm.com/docs/en/ztpf/2020?topic=cryptography-hardware-accelerators-perform-rsa-operations
[2]: https://www.nxp.com/docs/en/application-note/AN12445.pdf
