> Fair, although I think 99.9% of the value is in the trick Linux is doing here

For z/OS AT-TLS, the primary use case is that I can take a legacy app which knows nothing about TLS, and make it support TLS with zero code changes. You create policy rules in the OS configuration, they resemble firewall rules (they can match on source and destination address, port and process name), and if an application's socket call matches the rule, the plain socket gets transparently swapped with a TLS one.

Linux kernel TLS is trying to address a completely different use case: I have an app which knows all about TLS and already has the code (most likely via some shared library such as OpenSSL) to do it all by itself, but I'm going to modify it to move some of the processing to kernel space for improved performance.

What @simias was asking for, "I also firmly believe that SSL/TLS should've been handled at the OS level instead of everybody shipping their own custom OpenSSL implementations (complete with various vulnerabilities). I wish I could just use some setsockopt() syscalls to tell the OS I want a secure socket and let it figure out the rest" isn't exactly either use case, but it is closer to z/OS AT-TLS use case than Linux kTLS use case. Indeed, AT-TLS supports a mode of operation in which, rather than configuring TLS to be automatically applied by rules, it is manually requested by the app calling an ioctl on the socket - but, all the TLS configuration like which certificates to trust is pulled from the OS configuration - that seems like almost exactly what @simias was requesting.

> The handshake is at once the most complicated part (which means you don't really want it in Ring Zero)

I don't have a lot of insight into how AT-TLS is implemented internally, but I know some parts of it run in user space (inside a daemon called "pagent"). Having TLS implemented in the operating system doesn't necessarily mean it has to be implemented in the kernel. Some operating systems (e.g. Windows NT) say that the system call interface is private and the public interface is a library call. If an OS goes with that model, then the OS-supplied TLS implementation could be in a shared library not inside the kernel. Of course, that isn't the model Linux went with, it made system calls a public interface and so even if you put an AT-TLS-style transparent TLS implementation in the C library, some apps would bypass it by using system calls directly.

That isn't necessarily problematic. Actually, z/OS AT-TLS gets bypassed by some apps too. z/OS, being an operating system with decades of legacy, actually has multiple sockets APIs, and AT-TLS doesn't hook them all (whether due to technical limitations or simply IBM didn't decide it was worthwhile spending resources on.) In particular, the so-called "Pascal sockets API" (I believe it is called that because originally it was written in Pascal, and designed for use by Pascal code, but programs written in other languages such as C or COBOL or assembler can call it) doesn't go through AT-TLS. Likewise, apps that use the UNIX SystemV STREAMS API don't work with AT-TLS either. However, only a minority of z/OS apps use either of those legacy sockets APIs, and using those APIs is discouraged for new code. So, somewhat like z/OS does, if someone wanted to add this feature to Linux, they could always put it in the C library, and if an app bypassed that, well "sorry you don't get the transparent TLS feature".

Another option would be to do something like FUSE – have a daemon in user-space which does the TLS handshake. Inside the connect() or accept() system calls, the kernel could send the socket to that daemon, get it to do the TLS handshake, and then return the syscall when the daemon says it is done. All doable, the only real questions are (1) is anyone sufficiently motivated to add this feature to Linux (quite possibly not); (2) if they implement it, will the Linux kernel devs accept it (don't know about that either)