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

Message-ID: <20220607103028.15f70be6@kernel.org>
Date:   Tue, 7 Jun 2022 10:30:28 -0700
From:   Jakub Kicinski <kuba@...nel.org>
To:     Maxim Mikityanskiy <maximmi@...dia.com>
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 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. 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?