Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Explore kTLS for kernel TLS termination #5

Open
RaasAhsan opened this issue Mar 11, 2021 · 0 comments
Open

Explore kTLS for kernel TLS termination #5

RaasAhsan opened this issue Mar 11, 2021 · 0 comments

Comments

@RaasAhsan
Copy link

One of the main reasons why sendfile(2) and other zero-copy mechanisms (SOCKMAP via eBPF, splice(2), vmsplice(2)) don't work for edge services is the requirement of SSL/TLS.

SSL/TLS encryption forces the program to copy data into userland to have userland encryption applied to it before being sent back to the kernel.

In addition to disabling zero-copy mechanisms, userland crypto also prevents kernel primitives from introspecting data in transit, severely limiting the capabilities of eBPF programs.

To solve this, the Linux kernel has implemented kernel space TLS via a system called kTLS.

A 7% performance boost has been observed by using kTLS to re-enable sendfile(2). See the original kTLS paper for benchmark results: https://netdevconf.info/1.2/papers/ktls.pdf

I imagine that since kTLS, io_uring and even eBPF are newer additions to Linux, older kernel versions don't support it. Do you think it's worthwhile (or if it's even possible) to write code that falls back to other primitives for older kernels?

I think it's definitely possible in the case of kTLS and io_uring. This is effectively what glibc does. The worthwhile part is probably more of a case-by-case basis thing.

Doing a fallback for a kernel that doesn't have eBPF enabled seems way more challenging of a thing and might not be possible in certain eBPF use cases.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant