3 ms·

Generally the kernel is involved when it comes to making use of hardware. Specialized hardware emerges when widely applicable bottlenecks are identified, like r

Generally the kernel is involved when it comes to making use of hardware. Specialized hardware emerges when widely applicable bottlenecks are identified, like rendering 3D graphics, decoding video, or in this case TLS encryption. Not everything is destined for the kernel as userspace has generally desirable properties as well.

georgia_peach 5y ago
Last I checked, accelerated crypto instructions were unprivileged. Going by the article, this is just jamming the entire TLS hokey-pokey into kernelspace to avoid a copy. TLS session management is rather hairy. Judging by their Linux numbers, I'd take the performance hit over pushing something that complicated into the kernel.
- megous 5y ago
  There are also DMA based crypto accelerators (quite common, almost all computers in my home have one). Even those cheap $10 Orange Pi's.
- CyberRabbi 5y ago
  To be fair the hardware in question is not just accelerated crypto operations. From what I’ve read on this topic there are network cards that handle the end-to-end TLS protocol (sans negotiation). In general you have a point but it’s a judgement call like many things in engineering. Even in the absence of specialized TLS hardware, TLS operations are so common, there is a strong case for pushing it in the kernel if that improves efficiency by a double digit percentage. SSL_sendfile in particular is an efficiency boon for large static site hosts, it could result in significantly less hardware waste and/or reduced power consumption.
  - yencabulator 5y ago
    But if we're talking about offloading to a NIC, that can often be accessed directly from userspace, with a lot less kernel complexity. Pushing complexity into the kernel only makes sense when it's not immediately thereafter offloaded to easily-isolated hardware.
    - CyberRabbi 5y ago
      > that can often be accessed directly from userspace, with a lot less kernel complexity. Can you be more specific? Is this something that could be done with non-root privileges and without explicit coordination? Like normal TCP sockets?
      - yencabulator 5y ago
        This is how it normally looks: Modern hardware interacts with software ("drivers") by ringbuffers & data areas. To support this use case, the hardware generally provides multiple "logical devices". For example, https://en.wikipedia.org/wiki/Single-root_input/output_virtualization https://en.wikipedia.org/wiki/Single-root_input/output_virtu.... They're defined so that handing an untrusted party control of a logical device limits what they can do, e.g. what VLANs or other network overlays they can interact with. Each one gets its own ringbuffers etc. Another use case for the same hardware idea is virtual machines. Here, you can think of a userspace process as a virtual machine, minus all the overheads and pretense of being a whole computer. A userspace process is given access to the memory areas containing ringbuffers & data areas for a logical NIC. A library acts as a driver, and controls the NIC. All interaction is just reads & writes to memory, after setup the kernel is not involved at all.
        CyberRabbi 5y ago
        But in this setup, only a single process can use the logical device provided by the NIC. In kTLS case then multiple processes can share the logical device transparently.
        yencabulator 5y ago
        Sure, but there's usually something like 16 logical devices even in the less fancy hardware. And we're talking about nginx, generally there's only one of those -- the VM use case demands more, and that's the primary demand for the feature.
- toast0 5y ago
  Avoiding copies is useful, but AFAIK, this isn't jamimg the whole hokey-pokey into kernelspace. Only the bulk encryption (and probably? packetizing too), user space negotiates the session and just tells the kernel what it is. If there's anything that's not just application data, the kernel leaves it for userland. Bulk ciphering isn't hairy, and it's the same approach as IPSEC; userland negotiates sessions, kernel does the bulk ciphers.
- Aissen 5y ago
  The kernel code shouldn't do any session management. It just takes over once the handshake is done; the rest happens in userspace. Also, you're thinking of CPU-accelerated crypto, but you're missing two other use cases: here, coupled with sendfile(2), you can reduce the number of back-and-forth between kernel and userspace when you already know what will be written on the socket. The other use case is the (few, for now) network cards that do TLS in hardware, meaning going at line-rate, whatever your CPU speed is (not sure you can do single-thread 200Gbit/s crypto on x86_64).

georgia_peach 5y ago

Last I checked, accelerated crypto instructions were unprivileged. Going by the article, this is just jamming the entire TLS hokey-pokey into kernelspace to avoid a copy. TLS session management is rather hairy. Judging by their Linux numbers, I'd take the performance hit over pushing something that complicated into the kernel.

megous 5y ago
There are also DMA based crypto accelerators (quite common, almost all computers in my home have one). Even those cheap $10 Orange Pi's.
CyberRabbi 5y ago
To be fair the hardware in question is not just accelerated crypto operations. From what I’ve read on this topic there are network cards that handle the end-to-end TLS protocol (sans negotiation). In general you have a point but it’s a judgement call like many things in engineering. Even in the absence of specialized TLS hardware, TLS operations are so common, there is a strong case for pushing it in the kernel if that improves efficiency by a double digit percentage. SSL_sendfile in particular is an efficiency boon for large static site hosts, it could result in significantly less hardware waste and/or reduced power consumption.
- yencabulator 5y ago
  But if we're talking about offloading to a NIC, that can often be accessed directly from userspace, with a lot less kernel complexity. Pushing complexity into the kernel only makes sense when it's not immediately thereafter offloaded to easily-isolated hardware.
  - CyberRabbi 5y ago
    > that can often be accessed directly from userspace, with a lot less kernel complexity. Can you be more specific? Is this something that could be done with non-root privileges and without explicit coordination? Like normal TCP sockets?
    - yencabulator 5y ago
      This is how it normally looks: Modern hardware interacts with software ("drivers") by ringbuffers & data areas. To support this use case, the hardware generally provides multiple "logical devices". For example, https://en.wikipedia.org/wiki/Single-root_input/output_virtualization https://en.wikipedia.org/wiki/Single-root_input/output_virtu.... They're defined so that handing an untrusted party control of a logical device limits what they can do, e.g. what VLANs or other network overlays they can interact with. Each one gets its own ringbuffers etc. Another use case for the same hardware idea is virtual machines. Here, you can think of a userspace process as a virtual machine, minus all the overheads and pretense of being a whole computer. A userspace process is given access to the memory areas containing ringbuffers & data areas for a logical NIC. A library acts as a driver, and controls the NIC. All interaction is just reads & writes to memory, after setup the kernel is not involved at all.
      - CyberRabbi 5y ago
        But in this setup, only a single process can use the logical device provided by the NIC. In kTLS case then multiple processes can share the logical device transparently.
        yencabulator 5y ago
        Sure, but there's usually something like 16 logical devices even in the less fancy hardware. And we're talking about nginx, generally there's only one of those -- the VM use case demands more, and that's the primary demand for the feature.
toast0 5y ago
Avoiding copies is useful, but AFAIK, this isn't jamimg the whole hokey-pokey into kernelspace. Only the bulk encryption (and probably? packetizing too), user space negotiates the session and just tells the kernel what it is. If there's anything that's not just application data, the kernel leaves it for userland. Bulk ciphering isn't hairy, and it's the same approach as IPSEC; userland negotiates sessions, kernel does the bulk ciphers.
Aissen 5y ago
The kernel code shouldn't do any session management. It just takes over once the handshake is done; the rest happens in userspace. Also, you're thinking of CPU-accelerated crypto, but you're missing two other use cases: here, coupled with sendfile(2), you can reduce the number of back-and-forth between kernel and userspace when you already know what will be written on the socket. The other use case is the (few, for now) network cards that do TLS in hardware, meaning going at line-rate, whatever your CPU speed is (not sure you can do single-thread 200Gbit/s crypto on x86_64).