Date: Sun, 10 Jan 2021 21:41:58 -0800 From: John-Mark Gurney <jmg@funkthat.com> To: Andrew Gallatin <gallatin@cs.duke.edu> Cc: John Baldwin <jhb@FreeBSD.org>, freebsd-arch@FreeBSD.org, Rick Macklem <rmacklem@uoguelph.ca>, Allan Jude <allanjude@freebsd.org> Subject: Re: Should we enable KERN_TLS on amd64 for FreeBSD 13? Message-ID: <20210111054158.GM31099@funkthat.com> In-Reply-To: <993ebe97-d4b4-fe59-5b4f-9d607bb5e698@cs.duke.edu> References: <8eff83e5-49bc-d410-626e-603c03877b80@cs.duke.edu> <20210108214446.GJ31099@funkthat.com> <4fe4a57c-8c43-a677-4872-d0671104c414@FreeBSD.org> <20210109022409.GL31099@funkthat.com> <993ebe97-d4b4-fe59-5b4f-9d607bb5e698@cs.duke.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
Andrew Gallatin wrote this message on Sat, Jan 09, 2021 at 17:37 -0500:
> On 1/8/21 9:24 PM, John-Mark Gurney wrote:
> > John Baldwin wrote this message on Fri, Jan 08, 2021 at 17:03 -0800:
> >> On 1/8/21 1:44 PM, John-Mark Gurney wrote:
> >>> Andrew Gallatin wrote this message on Fri, Jan 08, 2021 at 12:26 -0500:
> >>>> Kernel TLS (KTLS) support was added roughly a year ago, and provides
> >>>> an efficient software or hardware accelerated path to have the kernel
> >>>> (or the NIC) handle TLS crypto. This is quite useful for web and
> >>>> NFS servers, and provides a huge (2x -> 5x) efficiency gain by
> >>>> avoiding data copies into userspace for crypto, and potentially
> >>>> offloading the crypto to hardware.
> >>>>
> >>>>
> >>>> KTLS is well tested on amd64, having been used in production at Netflix
> >>>> for nearly 4 years. The vast majority of Netflix video has been served
> >>>> via KTLS for the last few years. Its what has allowed us to serve
> >>>> 100Gb/s on Xeon 2697A cpus for years, and what allows us to serve
> >>>> nearly 400Gb/s on AMD servers with NICs which support crypto offload.
> >>>>
> >>>> I have received a few requests to enable it by default in GENERIC, and
> >>>> I'd like to get some opinions.
> >>>>
> >>>> There are essentially 3 options
> >>>>
> >>>> 1) Fully enable KTLS by adding 'options KERN_TLS' to GENERIC, and
> >>>> flipping kern.ipc.tls.enable=1
> >>>>
> >>>> The advantage of this is that it "just works" out of the box for users,
> >>>> and for reviewers.
> >>>>
> >>>> The drawback is that new code is thrust on unsuspecting users,
> >>>> potentially exposing them to bugs that we have not found in our
> >>>> somewhat limited web serving workload.
> >>>
> >>> This is my vote.
> >>>
> >>> I assume that the in tree and ports tree OpenSSL libraries will make
> >>> use of it when present? Does this mean fetch and the like will also
> >>> use it when talking w/ https website? (that's a nice benefit).
> >>
> >> In tree OpenSSL does not support KTLS. OpenSSL considers KTLS support
> >> too large of a feature to officially backport to the 1.1.1 branch, so
> >> if we add it in base, it will mean keeping it as a local diff.
> >>
> >> OTOH, I do maintain a backport of KTLS to 1.1.1 and there is a KTLS
> >> option for the security/openssl port (not on by default, it perhaps
> >> should be on 13?) which includes KTLS support. security/openssl-devel
> >> (which tracks OpenSSL 3) also has a KTLS option that probably should
> >> be enabled by default on 13 as it only consists of enabling the
> >> option without requiring patches to the port.
> >>
> >> I can raise the issue again with secteam about importing KTLS into the
> >> base OpenSSL. I think the main issue is the risk of getting a merge
> >> conflict when merging in an SA, though from my experience maintaining
> >> the KTLS patchset against 1.1.1 for the past year or so, I expect that
> >> risk to be fairly low.
> >
> > Considering that 1.1.1 support will end long before the support time of
> > 13-current ends, that's only two+ years of work to merge supported
> > patches, then we're on our own anyways..
>
>
> We (Netflix) have maintained patches to base openssl for several
> years, and I can recall only one tricky merge. But I think this
> ship has sailed. I'm not about to ask to make somebody else's
> life more difficult.
I mean, if you (Netflix) is already maintaing, and making the changes,
then it isn't making anyone's life more difficult if any future changes
that need to be done are contributed back to the project.
Or are you more saying that Netflix does not want to commit to doing
the necessary changes in a timely fashion when a SA comes out?
--
John-Mark Gurney Voice: +1 415 225 5579
"All that I will do, has been done, All that I have, has not."
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20210111054158.GM31099>