netdev - Re: [PATCH] tls: add zerocopy device sendpage

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]

Date:   Tue, 14 Jul 2020 23:56:06 +0300
From:   Boris Pismenny <borisp@...lanox.com>
To:     David Miller <davem@...emloft.net>
Cc:     kuba@...nel.org, john.fastabend@...il.com, daniel@...earbox.net,
        tariqt@...lanox.com, netdev@...r.kernel.org
Subject: Re: [PATCH] tls: add zerocopy device sendpage

On 14/07/2020 23:42, David Miller wrote:
> From: Boris Pismenny <borisp@...lanox.com>
> Date: Tue, 14 Jul 2020 10:27:11 +0300
>
>> Why is it the kernel's role to protect against such an error?
> Because the kernel should perform it's task correctly no matter what
> in the world the user does.
>
>> Surely the user that modifies pagecache data while sending it over
>> sendfile (with TCP) will suffer from consistency bugs that are even worse.
> No they won't, often times this is completely legitimate.  One task is
> doing a sendpage while another process with access to the file writes
> to it.
>
> And that's perfectly fine and allowed by the APIs.
>
> And we must set the IP checksums and TLS signatures correctly.
>
> I will not allow for an implementation that can knowingly send corrupt
> things onto the wire.

Not even if the user knows exactly what she is doing. For example, when
serving static files?

>> The copy in the TLS_DEVICE sendfile path greatly reduces the value of
>> all of this work. If we want to get the maximum out of this, then the
>> copy has to go.
>>
>> If we can't make this the default (as it is in FreeBSD), and we can't
>> add a knob to enable this. Then, what should we do here?
> I have no problem people using FreeBSD if it serves their needs better
> than Linux does.  If people want corrupt TLS signatures in legitimate
> use cases, and FreeBSD allows it, so be it.
>
> So don't bother using this as a threat or a reason for me to allow a
> feature or a change into the Linux networking.  It will never work.

This isn't what I intended to convey. I've used the FreeBSD implementation
to emphasize that the performance gain justifies including this despite
the implication on user applications.

> And, let me get this straight, from the very beginning you intended to
> try and add this thing even though I was %100 explicitly against it?

There was no intention to hide the correctness issue here. I've proposed
to expose it via a knob for this very reason. I'm sorry that I haven't
conveyed this more clearly in the commit message.