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]

Date:   Tue, 7 Jun 2022 14:08:00 -0700
From:   Stephen Hemminger <stephen@...workplumber.org>
To:     Jakub Kicinski <kuba@...nel.org>
Cc:     Maxim Mikityanskiy <maximmi@...dia.com>, dsahern@...il.com,
        netdev@...r.kernel.org, tariqt@...dia.com
Subject: Re: [PATCH iproute2-next v2] ss: Shorter display format for TLS
 zerocopy sendfile

On Tue, 7 Jun 2022 10:30:28 -0700
Jakub Kicinski <kuba@...nel.org> 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. 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?

Works for me