5 ms·

TLS libraries like OpenSSL operate in user space (in-kernel TLS is very a recent addition to Linux). sendfile(2)'s benefit is that it doesn't require transferr

TLS libraries like OpenSSL operate in user space (in-kernel TLS is very a recent addition to Linux). sendfile(2)'s benefit is that it doesn't require transferring the data back and forth between kernel space and user space. You point it to a file descriptor and a socket, and it simply copies the bytes -- all in kernel space.

messe 8y ago
> in-kernel TLS is very a recent addition to Linux Linux has gotten in-kernel TLS? That's slightly horrifying. Seems like it's hard enough to get right without being allowed to overwrite any user page you'd like.
- philjohn 8y ago
  Doesn't a lot of that come from the very long development history of OpenSSL (so best practices have developed over its lifetime), and the many, many compatibility hacks they still include in the codebase? It also contains a LOT of different things in there, whereas "just" a TLS stream with limited ciphers should be a lot simpler.
  - toast0 8y ago
    Supporting TLS directly in a kernel is horrifying regardless of the legacy of OpenSSL. Having userspace do the session establishment (where all the weird stuff happens) and letting the kernel do the bulk ciphering is reasonable, especially if you're already using sendfile so the kernel can handle the bulk data sending. If something goes sideways, punt the socket back to userspace. Lots of kernels already have bulk ciphering for encrypted disks or ipsec (which is often very similar, userspace negotiates sessions and kernel handles per packet ciphering)
    - ronsor 8y ago
      AFAIK that's all Linux's TLS implementation does -- ciphering & encryption, not session setup
- runlevel1 8y ago
  Yes, but only the symmetric part. You handshake in userspace, then you pass the negotiated cipher keys/IV to the TCP socket with `setsockopt`. Last I looked, the only cipher supported was AES-128-GCM.
  - caf 8y ago
    That's right. And if anything else happens on the connection (like a renegotiation) then it is just punted back to userspace.
    - alacombe 8y ago
      Which is the correct way to handle, fast data path in the kernel, slow control path in userspace.
  - messe 8y ago
    Ah, that's a lot more reasonable then.
- takeda 8y ago
  Don't know about Linux implementation, but sendfile would only need AES, and today's CPUs even come with hardware support. I can't talk about security aspect, but it is not like the openssl is implemented in kernel or hardware, just the symmetric encryption and that only transforms the data.

messe 8y ago

> in-kernel TLS is very a recent addition to Linux Linux has gotten in-kernel TLS? That's slightly horrifying. Seems like it's hard enough to get right without being allowed to overwrite any user page you'd like.

philjohn 8y ago
Doesn't a lot of that come from the very long development history of OpenSSL (so best practices have developed over its lifetime), and the many, many compatibility hacks they still include in the codebase? It also contains a LOT of different things in there, whereas "just" a TLS stream with limited ciphers should be a lot simpler.
- toast0 8y ago
  Supporting TLS directly in a kernel is horrifying regardless of the legacy of OpenSSL. Having userspace do the session establishment (where all the weird stuff happens) and letting the kernel do the bulk ciphering is reasonable, especially if you're already using sendfile so the kernel can handle the bulk data sending. If something goes sideways, punt the socket back to userspace. Lots of kernels already have bulk ciphering for encrypted disks or ipsec (which is often very similar, userspace negotiates sessions and kernel handles per packet ciphering)
  - ronsor 8y ago
    AFAIK that's all Linux's TLS implementation does -- ciphering & encryption, not session setup
runlevel1 8y ago
Yes, but only the symmetric part. You handshake in userspace, then you pass the negotiated cipher keys/IV to the TCP socket with `setsockopt`. Last I looked, the only cipher supported was AES-128-GCM.
- caf 8y ago
  That's right. And if anything else happens on the connection (like a renegotiation) then it is just punted back to userspace.
  - alacombe 8y ago
    Which is the correct way to handle, fast data path in the kernel, slow control path in userspace.
- messe 8y ago
  Ah, that's a lot more reasonable then.
takeda 8y ago
Don't know about Linux implementation, but sendfile would only need AES, and today's CPUs even come with hardware support. I can't talk about security aspect, but it is not like the openssl is implemented in kernel or hardware, just the symmetric encryption and that only transforms the data.