3 ms·

I think it was a bad idea to put cryptographic APIs or VPN in the kernel. If userspace is too slow for this, you should either reduce context switch overhead, o

I think it was a bad idea to put cryptographic APIs or VPN in the kernel. If userspace is too slow for this, you should either reduce context switch overhead, or create special kind of processes, which are isolated, but quick to switch into. They are repeating Windows mistakes.

deleted 5mo ago
[deleted]
ohnei 5mo ago
I don't think it was a bad idea, doing any idea requires an investment and a better investment would have been kernel layer, just ask the history of export control law what the US feared breaking more. Having security in userland means attacks in kernel or in userland are worthwhile against it. In the kernel it could have been secured better than OpenSSL was with less resources and could have had keys unavailable from userland. Instead it got basically no uptake as everyone hobbled along on slightly more resources spread even thinner on OpenSSL clones.
cormorant 5mo ago
It's not faster than userspace, it's much slower normally. On special boards with crypto accelerators it can be faster, and there can be compliance reasons to want it. References: [1] https://www.chronox.de/libkcapi/html/ch01s02.html https://www.chronox.de/libkcapi/html/ch01s02.html [2] https://lwn.net/Articles/410763/ https://lwn.net/Articles/410763/ [3] https://trac.gateworks.com/wiki/linux/encryption#PerformaceComparisons https://trac.gateworks.com/wiki/linux/encryption#PerformaceC...
cpach 5mo ago
Well at least if it’s crufty stuff like AF_ALG that barely no-one is using and is kind of a forgotten place of the kernel. I don’t oppose reasonable crypto in the kernel, like WireGuard.
- cluckindan 5mo ago
  >barely no-one is using Except, you know, many things
  - cpach 5mo ago
    Many? No, I don’t agree.
nwallin 5mo ago
I like the idea of keeping stuff out of the kernel as much as possible, but in this case, there are good reasons why cryptography has to live in the kernel. We need on disk encryption, and we need to be able boot from an encrypted disk. So we need encryption for that. We need network filesystems, and we need the traffic over the network to be encrypted. So we need encryption. IPsec, for better or for worse, is authenticated and partially encrypted at the transport layer, so if we want a linux machine to speak IPsec, we need encryption. Fixing/changing this would require a huge restructuring of the kernel; it would basically require switching to a microkernel. Given the fact that nobody's ever written a microkernel that doesn't completely suck ass, I don't know that it would be worth the effort.
- ranger_danger 5mo ago
  What about having a way to run the same crypto code but in userspace? Or perhaps turn it into a library that can be used from userspace.
  - Anonbrit 5mo ago
    For encrypted disks, you've now got high-performance data shuffling between userspace and kernel space - a massive new attack surface
- cpach 5mo ago
  Sure. But it would probably still be a good thing if the kernel maintainers could tear out AF_ALG.
pjmlp 5mo ago
Those Windows mistakes have been sorted out for a long time now.

deleted 5mo ago

[deleted]

ohnei 5mo ago

I don't think it was a bad idea, doing any idea requires an investment and a better investment would have been kernel layer, just ask the history of export control law what the US feared breaking more. Having security in userland means attacks in kernel or in userland are worthwhile against it. In the kernel it could have been secured better than OpenSSL was with less resources and could have had keys unavailable from userland. Instead it got basically no uptake as everyone hobbled along on slightly more resources spread even thinner on OpenSSL clones.

cormorant 5mo ago

It's not faster than userspace, it's much slower normally. On special boards with crypto accelerators it can be faster, and there can be compliance reasons to want it. References: [1] https://www.chronox.de/libkcapi/html/ch01s02.html https://www.chronox.de/libkcapi/html/ch01s02.html [2] https://lwn.net/Articles/410763/ https://lwn.net/Articles/410763/ [3] https://trac.gateworks.com/wiki/linux/encryption#PerformaceComparisons https://trac.gateworks.com/wiki/linux/encryption#PerformaceC...

cpach 5mo ago

Well at least if it’s crufty stuff like AF_ALG that barely no-one is using and is kind of a forgotten place of the kernel. I don’t oppose reasonable crypto in the kernel, like WireGuard.

cluckindan 5mo ago
>barely no-one is using Except, you know, many things
- cpach 5mo ago
  Many? No, I don’t agree.

nwallin 5mo ago

I like the idea of keeping stuff out of the kernel as much as possible, but in this case, there are good reasons why cryptography has to live in the kernel. We need on disk encryption, and we need to be able boot from an encrypted disk. So we need encryption for that. We need network filesystems, and we need the traffic over the network to be encrypted. So we need encryption. IPsec, for better or for worse, is authenticated and partially encrypted at the transport layer, so if we want a linux machine to speak IPsec, we need encryption. Fixing/changing this would require a huge restructuring of the kernel; it would basically require switching to a microkernel. Given the fact that nobody's ever written a microkernel that doesn't completely suck ass, I don't know that it would be worth the effort.

ranger_danger 5mo ago
What about having a way to run the same crypto code but in userspace? Or perhaps turn it into a library that can be used from userspace.
- Anonbrit 5mo ago
  For encrypted disks, you've now got high-performance data shuffling between userspace and kernel space - a massive new attack surface
cpach 5mo ago
Sure. But it would probably still be a good thing if the kernel maintainers could tear out AF_ALG.

pjmlp 5mo ago

Those Windows mistakes have been sorted out for a long time now.