3 ms·
The kernel driver forwards the heavy lifting to a user-space daemon that manages the TCP socket (using standard API) and implements TLS.
by mayoff 8y ago
The kernel driver forwards the heavy lifting to a user-space daemon that manages the TCP socket (using standard API) and implements TLS.
- zrm 8y agoThen why not move the user-space code into the original user process as part of the standard library?
- mayoff 8y agoRead section 8.2 of the paper.
- zrm 8y agoThey make two main points: > By implementing the SSA with a kernel module, developers who wish to use it do not have to link with any additional userspace libraries. It's not clear why this is a major problem to begin with, but socket() and friends are part of libc, which would be the natural place for something using this type of interface and would then already be linked. > Adding TLS to the Linux kernel as an Internet protocol allows the SSA to leverage the existing separation of the system call boundary. The main benefit of this (as they mention) is to separate access to the private key(s). But that could be done for only the private key (signing operation) instead of the entire TLS protocol and would then be generically useful, e.g. for non-TLS protocols that require signing, would provide a standard interface in case you have a HSM, and could be used by a libc implementation or any other TLS implementation.