
TLS in Linux 4.13 kernel - agumonkey
https://github.com/torvalds/linux/blob/master/Documentation/networking/tls.txt
======
corbet
LWN's coverage of this patch:
[https://lwn.net/Articles/666509/](https://lwn.net/Articles/666509/)

~~~
SEMW
Thanks Jonathan.

Everyone: the above gives a lot of very helpful context & explanation for this
(from when the patch was first posted in Dec 2015)

~~~
caf
The merged patch does have some significant points of difference from the one
described in 2015, though.

------
zingplex
Wouldn't implementing TLS in the kernel result in a substantial increase in
the exposed attack surface? This seems to me as if it would be similar to the
time that Windows moved the graphics into the kernel and the havoc that ensued
thereafter.

~~~
topspin
It appears the design of KTLS is intended to minimize the complexity necessary
inside the kernel; the TLS handshake is handled in user space and then the TLS
state is transcribed to a KTLS file descriptor which handles the traffic
thereafter. This means the very complex public key part of TLS is user space.
The kernel isn't involved with certificates etc. The kernel handles the
symmetric cryptography once the user space handshake is complete. So yes, the
net attack surface inside the kernel increases, but it isn't as though they
are embedding some OpenSSL equivalent into the kernel.

The paper reports a relatively small performance improvements. But I suppose
if you're Facebook (they and RedHat implemented this) and performance
improvements are measured in millions of dollars you care a lot about 7% less
CPU utilization.

~~~
phkahler
>> The paper reports a relatively small performance improvements. But I
suppose if you're Facebook (they and RedHat implemented this) and performance
improvements are measured in millions of dollars you care a lot about 7% less
CPU utilization.

You think 7 percent is a small performance improvement? IMHO it's rather
large. I take the time for much smaller than that.

To understand why, let me ask a question do you think doubling performance is
a good thing? In other words a 100 percent increase in throughput or a 50
percent reduction in execution time. I hope your answer is yes because a lot
of people think so. So what's 7 percent? Well imagine there are 7 different
areas of your code that could be improved with each one contributing 7
percent. That's 49 percent or about what we'd call a significant improvement.
Fixing up a number of single digit things adds up. But there is a more
sinister side to it. Suppose you wanted to let those 7 little things go, and
look for the big fish - the one that's going to get you 50 percent all in one
shot. Guess what? It doesn't exist. Why? Because these little things add up to
about half of your time, so to find the big one would imply taking the
execution time for _the rest of the code_ down to zero, because that's the
only place there's 50 percent left. Unless you're doing something really
poorly, there isn't a big win to be had. Performance comes from compounding
the effects of many small optimizations.

If just moving TLS from the application to the kernel gives 7 percent -
presumably by eliminating overhead - that's a good thing. Even if it's just 7
percent of time in communication which is only a portion of application
performance, it's still a good thing.

\--- note, this is a comment about performance and says nothing about
tradeoffs in security by putting TLS in kernel ---

~~~
topspin
>> You think 7 percent is a small performance improvement?

I think a 7% reduction in CPU utilization for TLS is small given the vast bulk
of systems that spend most of their time IO bound on network interfaces and/or
storage and will see little to no improvement in throughput. I allowed that
Facebook may see this as an important improvement given their scale; it could
be worth millions of dollars in power and/or hardware.

>> that's a good thing ... it's still a good thing.

Sure, it's good. I didn't characterize anything as "bad," merely "small."

------
dfhgb
the real advantage is that you can pass arround your encrypted connection as a
file descriptor. so when you add encryption to some service, you do not have
to manually replace all calls to read/write by libssl library functions but
instead you can just continue to use read()/write() calls. pass tls connection
as stdin/stdout to another process ect...

this is how plan9 does tls and how it really should have been in the first
place. adding tls support is one function call to wrap an existing file
descriptor in tls and you get another file descriptor back.

~~~
colanderman
But you can accomplish that by simply having an external process or thread
terminate the TLS connection, and connect to your process over Unix domain
sockets.

Of course that is inefficient. But that is what KTLS is at its core: an
optimization.

~~~
dfhgb
of course you can make a pipe and spawn a process that does the translation.
why's nobody doing that? because linux is a cargo cult and nobody does the
sane thing until it is provided by the infrastructure. because of fork not
mixing well with multithreaded applications... now finally linux got its shit
together so there is no more excuse why todo it in a covoluted way.

------
ComodoHacker
No mention of memory cleaning policy and other security guarantees. I hope
this is handled properly.

------
kev009
It's too bad KTLS was completed for FreeBSD but still not integrated.

~~~
drewg123
We're working on it. What we had was great for us, but pretty complex and not
really upstreamable.

I'm almost done with re-writing it to use the same M_NOTREADY mechanism as
async sendfile, and to do all the framing in the kernel, rather than doing the
sendfile() framing in-kernel and sosend() in userspace. This removes the
majority of the code, and makes it quite a bit simpler. The downside is that
it depends on my vectorized mbufs. Hopefully we'll have something public in
the next few months.

~~~
X86BSD
Just offering a few words of thanks and encouragement for your work regarding
this. When this is ready it's ready. But thank you in advance.

------
Skunkleton
I wonder why they opted not to use the existing packet transformation code
that is already in the kernel? The same code is used as part of linux ipsec
implementations.

~~~
_wmd
The layering inside the kernel is completely different...

    
    
        Kernel Connection Multiplexor
        
        Facebook’s primary motivation was to gain access to the un-encrypted bytes
        in kernel space. KCM is used to decode the framing, and make intelligent
        scheduling choices, before sending the frames to user space. KTLS sockets
        are mapped 1:N to user space sockets, where N is the number of user space
        threads, which are usually mapped to cores. Using this scheme, KTLS + KCM
        is able to reduce the total number of thread migrations of an individual
        request

------
TheAceOfHearts
Maybe the link should be updated to use the 4.13 tag [0] instead of the master
branch.

[0]
[https://github.com/torvalds/linux/blob/v4.13/Documentation/n...](https://github.com/torvalds/linux/blob/v4.13/Documentation/networking/tls.txt)

------
BenjiWiebe
What's funny, is that I was just reviewing my custom built kernel's
menuconfig, saw TLS, and briefly wondered why I didn't recall seeing that when
I first ran the config, then figured I had just missed it. Never thought maybe
it had recently been added.

------
weddpros
In these days of containers, wouldn't it allow a government to coerce a
container-hosting company into using an unsecure kernel? Such a kernel would
see all traffic, unencrypted... or did I miss something?

~~~
jo909
Please don't believe for even a second that your container host can't already
extract the cleartext just because the SSL is executed in the container
context.

A kernel facility like that certainly makes an attack even more obvious and
maybe harder to detect. But if this is a concern you can't use external
hosting.

This applies to VMs too, the hypervisor can see and transparently modify
everything going on. There is development going on with special CPU
instructions that could prevent the hypervisor from reading VM memory, but
that is not state of the art and I would not trust it for a long time.

You can't even be really sure that a bare metal server you are renting is not
extracting the cleartext via a modified bios/efi, bootloader etc, or modified
hardware at the worst.

~~~
weddpros
"that certainly makes it even more obvious": that's what I meant... easy mass
surveillance

~~~
jo909
If a government wants to do that, and the hosting company is not able or
willing to fight it on a legal basis, it's really not about how easy or hard
the actual implementation is. This makes nearly zero difference in the grand
scheme of such a surveillance program.

------
drudru11
Oh man - this is great. I hate having these proxy processes just for this
task.

I will begin experimenting with this kernel this week.

------
snakeanus
This is why we need microkernels.

~~~
geofft
Can you explain this position?

In particular, my impression is that a large reason of why microkernels failed
in the '90s - see e.g. OSF/1 - was the overhead of message-passing. The two
most popular kernels today that vaguely resemble microkernels, namely Darwin
(Mach-based) and NT (with its subsystems), do no isolation between parts of
their kernel and just have ordinary function calls. TLS exists in userspace
and works extraordinarily well, but the desire to move parts into kernelspace
is specifically to avoid the overhead of copying data between kernelspace and
userspace and to allow using things like sendfile() that wouldn't be possible
across address spaces.

~~~
MrTonyD
I think he meant to say that we need unikernels - a lot of people (including
me) sometimes make that same mistake.

------
rkeene2
This looks similar to AT-TLS (application transparent TLS) on IBM mainframes.

------
0xFFC
Please link to pdf?

~~~
citrusui
Here you go:
[https://netdevconf.org/1.2/papers/ktls.pdf](https://netdevconf.org/1.2/papers/ktls.pdf)

