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] [thread-next>] [day] [month] [year] [list]

Message-ID: <9d13245f-4c0d-c377-fecf-c8f8d9eace2a@mellanox.com>
Date:   Tue, 14 Jul 2020 01:15:26 +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 13/07/2020 22:05, David Miller wrote:
> From: Boris Pismenny <borisp@...lanox.com>
> Date: Mon, 13 Jul 2020 10:49:49 +0300
>
>> An alternative approach that requires no knobs is to change the
>> current TLS_DEVICE sendfile flow to skip the copy. It is really
>> not necessary to copy the data, as the guarantees it provides to
>> users, namely that users can modify page cache data sent via sendfile
>> with no error, justifies the performance overhead.
>> Users that sendfile data from the pagecache while modifying
>> it cannot reasonably expect data on the other side to be
>> consistent. TCP sendfile guarantees nothing except that
>> the TCP checksum is correct. TLS sendfile with copy guarantees
>> the same, but TLS sendfile zerocopy (with offload) will send
>> the modified data, and this can trigger an authentication error
>> on the TLS layer when inconsistent data is received. If the data
>> is inconsistent, then letting the user know via an error is desirable,
>> right?
>>
>> If there are no objections, I'd gladly resubmit it with the approach
>> described above.
> The TLS signatures are supposed to be even stronger than the protocol
> checksum, and therefore we should send out valid ones rather than
> incorrect ones.

Right, but one is on packet payload, while the other is part of the payload.

>
> Why can't the device generate the correct TLS signature when
> offloading?  Just like for the protocol checksum, the device should
> load the payload into the device over DMA and make it's calculations
> on that copy.

Right. The problematic case is when some part of the record is already
received by the other party, and then some (modified) data including
the TLS authentication tag is re-transmitted.
The modified tag is calculated over the new data, while the other party
will use the already received old data, resulting in authentication error.

>
> For SW kTLS, we must copy.  Potentially sending out garbage signatures
> in a packet cannot be an "option".
Obviously, SW kTLS must encrypt the data into a different kernel buffer,
which is the same as copying for that matter. TLS_DEVICE doesn't require this.