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  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]
Date:   Mon, 13 Jul 2020 12:05:30 -0700 (PDT)
From:   David Miller <davem@...emloft.net>
To:     borisp@...lanox.com
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

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.

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.

For SW kTLS, we must copy.  Potentially sending out garbage signatures
in a packet cannot be an "option".

Powered by blists - more mailing lists