netdev - Re: [PATCH v2] sock: allow reading and changing sk

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:   Mon, 2 Aug 2021 09:11:02 -0700
From:   Jakub Kicinski <kuba@...nel.org>
To:     Pavel Tikhomirov <ptikhomirov@...tuozzo.com>
Cc:     netdev@...r.kernel.org, "David S. Miller" <davem@...emloft.net>,
        Arnd Bergmann <arnd@...db.de>,
        Eric Dumazet <edumazet@...gle.com>,
        Paolo Abeni <pabeni@...hat.com>,
        Florian Westphal <fw@...len.de>, linux-kernel@...r.kernel.org,
        linux-alpha@...r.kernel.org, linux-mips@...r.kernel.org,
        linux-parisc@...r.kernel.org, sparclinux@...r.kernel.org,
        linux-arch@...r.kernel.org, Andrei Vagin <avagin@...il.com>
Subject: Re: [PATCH v2] sock: allow reading and changing sk_userlocks with
 setsockopt

On Mon, 2 Aug 2021 11:26:09 +0300 Pavel Tikhomirov wrote:
> On 30.07.2021 19:46, Jakub Kicinski wrote:
> > On Fri, 30 Jul 2021 19:07:08 +0300 Pavel Tikhomirov wrote:  
> >> SOCK_SNDBUF_LOCK and SOCK_RCVBUF_LOCK flags disable automatic socket
> >> buffers adjustment done by kernel (see tcp_fixup_rcvbuf() and
> >> tcp_sndbuf_expand()). If we've just created a new socket this adjustment
> >> is enabled on it, but if one changes the socket buffer size by
> >> setsockopt(SO_{SND,RCV}BUF*) it becomes disabled.
> >>
> >> CRIU needs to call setsockopt(SO_{SND,RCV}BUF*) on each socket on
> >> restore as it first needs to increase buffer sizes for packet queues
> >> restore and second it needs to restore back original buffer sizes. So
> >> after CRIU restore all sockets become non-auto-adjustable, which can
> >> decrease network performance of restored applications significantly.
> >>
> >> CRIU need to be able to restore sockets with enabled/disabled adjustment
> >> to the same state it was before dump, so let's add special setsockopt
> >> for it.
> >>
> >> Signed-off-by: Pavel Tikhomirov <ptikhomirov@...tuozzo.com>  
> > 
> > The patchwork bot is struggling to ingest this, please double check it
> > applies cleanly to net-next.  
> 
> I checked that it applies cleanly to net-next:
> 
> [snorch@...ora linux]$ git am 
> ~/Downloads/patches/ptikhomirov/setsockopt-sk_userlocks/\[PATCH\ v2\]\ 
> sock\:\ allow\ reading\ and\ changing\ sk_userlocks\ with\ setsockopt.eml
> 
> [snorch@...ora linux]$ git log --oneline
> c339520aadd5 (HEAD -> net-next) sock: allow reading and changing 
> sk_userlocks with setsockopt
> 
> d39e8b92c341 (net-next/master) Merge 
> https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next
> 
> Probably it was some temporary problem and now it's OK? 
> https://patchwork.kernel.org/project/netdevbpf/patch/20210730160708.6544-1-ptikhomirov@virtuozzo.com/

Indeed, must have been resolved by the merge of net into net-next which
happened on Saturday? Regardless, would you mind reposting? There is no
way for me to retry the patchwork checks.

And one more thing..

> +	case SO_BUF_LOCK:
> +		sk->sk_userlocks = (sk->sk_userlocks & ~SOCK_BUF_LOCK_MASK) |
> +				   (val & SOCK_BUF_LOCK_MASK);

What's the thinking on silently ignoring unsupported flags on set
rather than rejecting? I feel like these days we lean towards explicit
rejects.

> +	case SO_BUF_LOCK:
> +		v.val = sk->sk_userlocks & (SOCK_SNDBUF_LOCK | SOCK_RCVBUF_LOCK);
> +		break;

The mask could you be used here.

Just to double check - is the expectation that the value returned is
completely opaque to the user space? The defines in question are not
part of uAPI.