[codedokode]

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.

[cormorant]

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 [2] https://lwn.net/Articles/410763/ [3] https://trac.gateworks.com/wiki/linux/encryption#PerformaceC...

[cpach]

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]

>barely no-one is using

Except, you know, many things

[cpach]

Many? No, I don’t agree.

[nwallin]

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]

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]

For encrypted disks, you've now got high-performance data shuffling between userspace and kernel space - a massive new attack surface

[cpach]

Sure. But it would probably still be a good thing if the kernel maintainers could tear out AF_ALG.

[ohnei]

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.

[pjmlp]

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