One reason to use up-to-date #Linux kernels on your production servers is that they can do things faster. Linux 4.13+ has kTLS or kernel-level (!) TLS stack.
https://www.kernel.org/doc/html/latest/networking/tls-offload.html
@kravietz Wow, TLS in the kernel? Doesn't that pose a risk of slower rollout for bugfixes? Hasn't basically every TLS implementation suffered a critical vulnerability at one time or another?
I don't think any extra randomness source can weaken anything, it's not like entropy pools work. BTW kernel already has plenty of crypto code eg for IPSec, secure boot etc
@kravietz @abliss and there's never been issues with any of that "robust" code ever.
You'll recall that the resignation happened because an extra randomness source was *removed* by relying directly on intel's hardware solely, thus showing that bad management decisions (this was pushed by Linus himself) can sometimes compromise security by weakening entropy. Might be best to keep that stuff out-of-kernel.
You'll recall that the resignation happened because an extra randomness source was *removed* by relying directly on intel's hardware solely, thus showing that bad management decisions (this was pushed by Linus himself) can sometimes compromise security by weakening entropy. Might be best to keep that stuff out-of-kernel.
If you're trying to advocate for microkernels then well, both kTLS and IPSec are already available as modules
Hey, remember that time a kernel maintainer resigned because an Intel-influenced RDRAND decision decisively weakened the kernel's ability to generate random numbers? That was fun to watch. IIRC, Ted Tso took over afterwards.