Speaker
Description
Linux Crypto API has recently come under fire due to a series of discovered vulnerabilities, like Copy Fail and friends. This resulted in a drastic response from some maintainers: deprecation of the Linux Crypto API userspace interface. However, it feels like cracking a nut with a sledgehammer, as some vulnerabilities, like Dirty Frag, do not even use the userspace interface directly for the exploit.
Doing crypto in the kernel on behalf of userspace code may bring some security and efficiency advantages:
- the key material is not exposed to the process address space anymore, which can save the key from very common memory bugs (remember Heartbleed?)
- abstracting the key material as a kernel object (e.g., a file descriptor) allows sharing the key usage across unprivileged applications without giving those applications access to the key material (software HSM/KMS use case, cloud workloads, K8s)
- the kernel is best positioned to abstract modern cryptographic hardware and allow applications to utilize it and reap the performance benefits
- highly-constrained embedded systems may have fewer dependencies as they don't have to pull extra crypto libraries such as OpenSSL or gcrypt into their firmware
One of the reasons quoted for the deprecation is that the userspace Linux Crypto API interface is not efficient anyway and there are very few users. But maybe there are few users, because it is not very efficient and apparently insecure? What if instead of disabling it we improve it or even redesign? For example:
- replace the splice()-based zero-copy interface (which was targeted by the vulnerabilities in the first place and is not truly zero-copy anyway) with a modern primitive such as io_uring
- fix the limitation of authenticated encryption being able to process only ~64k of data
- replace the confusing network-based AF_ALG protocol with something simpler, such as plain device files/sysfs
- use eBPF to expose Linux Crypto API to userspace in a more constrained and controllable manner
- limit the number of algorithms exposable to userspace – only general-purpose algorithms should be exposed
The goal of this session is to reach a shared view on whether the userspace Linux Crypto API is worth saving and, if so, what a v2 should look like.