netdev - Re: Revive zerocopy TLS sendfile

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20220309081116.5455a4ae@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com>
Date:   Wed, 9 Mar 2022 08:11:16 -0800
From:   Jakub Kicinski <kuba@...nel.org>
To:     Maxim Mikityanskiy <maximmi@...dia.com>
Cc:     "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "David S. Miller" <davem@...emloft.net>,
        Saeed Mahameed <saeedm@...dia.com>,
        Tariq Toukan <tariqt@...dia.com>, Gal Pressman <gal@...dia.com>
Subject: Re: Revive zerocopy TLS sendfile

On Wed, 9 Mar 2022 08:48:16 +0000 Maxim Mikityanskiy wrote:
> We would like to revive the discussion on zerocopy sendfile support for
> TLS offload:
> 
> https://lore.kernel.org/all/1594551195-3579-1-git-send-email-borisp@mellanox.com/
> 
> I believe we can resolve the concern about correctness vs performance
> expressed in the previous discussion.
> 
> Historically, sendfile implementations for TCP and TLS allow changing
> the underlying file while sending it. The connection is not disrupted,
> but besides that there aren't many guarantees: the contents of the
> received file may be a mix of the old and new versions (a lost middle
> packet may be retransmitted with the new data, after the packets
> following it were received with the old data). The goal is to preserve
> this behavior for all existing users.
> 
> Zerocopy TLS sendfile provides even fewer guarantees: if a part of a TLS
> record is being retransmitted on TCP level, while the file is being
> changed, the receiver may get a TLS record with bad signature and close
> the connection. That means we can't simply replace the current behavior
> with zerocopy.

It is the ZC TLS sendfile w/ offload you mean here? We use the term ZC
for too many things :S

> On the other hand, even with such a limitation, zerocopy TLS sendfile is
> extremely useful in a very common use case of serving static files over
> HTTPS. Web files normally have formats that become damaged and useless
> after arbitrary partial updates. From that perspective, receiving a
> damaged file or closing the connection is equally bad for the client.
> Admins should normally avoid updating static files without stopping the
> server, but even if they don't follow this recommendation, zerocopy
> itself doesn't impair user experience compared to regular sendfile. At
> the same time, it boosts the TX speed by up to 25% and reduces CPU load
> by up to 12.5%.
> 
> Given that we would like to keep the current sendfile behavior for all
> existing users, while still being able to use acceleration of zerocopy
> in applicable scenarios, I suggest considering including zerocopy TLS
> sendfile as an opt-in feature. The default will always be non-zerocopy,
> and there will be no global sysctl knob to change it, so that it won't
> be possible to break existing applications. The users willing to use
> zerocopy deliberately will set a flag, for example, by setsockopt (or
> any other mechanism).
> 
> Most importantly, there is no concern of violating kernel integrity. The
> userspace won't be able to crash the kernel or bypass protection using
> the new feature. It also won't be able to trick the kernel into
> transmitting some data that the userspace can't send using a regular TCP
> socket.
> 
> What do you think about these points? Does zerocopy TLS sendfile have a
> future in the kernel as an opt-in feature?

Opt-in sounds reasonable to me.