netdev - Re: [PATCH iproute2-next v2] ss: Shorter display format for TLS zerocopy 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]

Date:   Wed, 8 Jun 2022 13:04:44 +0300
From:   Maxim Mikityanskiy <maximmi@...dia.com>
To:     Jakub Kicinski <kuba@...nel.org>
Cc:     dsahern@...il.com, netdev@...r.kernel.org,
        stephen@...workplumber.org, tariqt@...dia.com
Subject: Re: [PATCH iproute2-next v2] ss: Shorter display format for TLS
 zerocopy sendfile

On 2022-06-07 20:30, Jakub Kicinski wrote:
> On Tue, 7 Jun 2022 13:35:19 +0300 Maxim Mikityanskiy wrote:
>>> That'd be an acceptable compromise. Hopefully sufficiently forewarned
>>> users will mentally remove the zc_ part and still have a meaningful
>>> amount of info about what the flag does.
>>>
>>> Any reason why we wouldn't reuse the same knob for zc sendmsg()? If we
>>> plan to reuse it we can s/sendfile/send/ to shorten the name, perhaps.
>>
>> We can even make it as short as zc_ro_tx in that case.
> 
> SG
> 
>> Regarding sendmsg, I can't anticipate what knob will be used. There is
>> MSG_ZEROCOPY which is also a candidate.
> 
> Right, that's what I'm wondering. MSG_ZEROCOPY already has some
> restrictions on user not touching the data but technically a pure
> TCP connection will not be broken if the data is modified.

Sounds similar to sendfile. With bare TCP, the user shouldn't modify the 
sendfile data, but the connection isn't broken in any case. With TLS, 
the connection may be broken, so we require an explicit opt-in. So, I 
think, a similar rule for MSG_ZEROCOPY will make sense: MSG_ZEROCOPY 
works out of the box with bare TCP, because the connection can't be 
severed by modifying data, but it will require an opt-in for TLS.

> I'd lean
> towards requiring the user setting zc_ro_tx, but admittedly I don't
> have a very strong reason.
> 
>> Note that the constant in the header file has "SENDFILE" in its name, so
>> if you want to reuse it for the future sendmsg zerocopy, we should think
>> about renaming it in advance, before anyone starts using it.
>> Alternatively, an alias for this constant can be added in the future.
> 
> Would be good to rename it to whatever we settle for on the iproute2
> side. Are we going with zc_ro_tx, then?

Yes, I'll submit the patches.