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, 15 Mar 2016 11:09:50 -0700
From:	Eric Dumazet <eric.dumazet@...il.com>
To:	Sowmini Varadhan <sowmini.varadhan@...cle.com>
Cc:	santosh shilimkar <santosh.shilimkar@...cle.com>,
	netdev@...r.kernel.org, davem@...emloft.net
Subject: Re: [PATCH v2 net-next] rds-tcp: Add sysctl tunables for
 sndbuf/rcvbuf on rds-tcp socket

On Tue, 2016-03-15 at 13:30 -0400, Sowmini Varadhan wrote:
> On (03/15/16 10:18), Eric Dumazet wrote:
> > 
> > Look at SO_SNDBUF and SO_RCVBUF implementation.
> > 
> > sk->sk_sndbuf = max_t(u32, val * 2, SOCK_MIN_SNDBUF);
> > 
> > sk->sk_rcvbuf = max_t(u32, val * 2, SOCK_MIN_RCVBUF);
> > 
> > kernel definitely has some logic here.
> 
> Ok, I can do the same thing (and we do this consistently across
> all drivers?)
> 
> > If you believe SOCK_MIN_SNDBUF and/or SOCK_MIN_RCVBUF are wrong, please
> > elaborate.
> 
> I dont recall suggesting that.

You said "just as user-space SO_SNDBUF allows ridiculous values
for buffer size.."

So I understood you believe SOCK_MIN_SNDBUF and/or SOCK_MIN_RCVBUF are
ridiculous ;)


> 
> BTW, when I tried it, doing a SO_SNDBUF of 1 from uspace does not return
> an error. It merely sets the buffer size to 4608 (as reported by
> getsockopt in my env. I think the getsockopt value is impacted by
> many factors).

I pointed to you the actual code.

sk->sk_sndbuf = max_t(u32, val * 2, SOCK_MIN_SNDBUF);


No error is returned. kernel enforces a minimal value.

#define SOCK_MIN_SNDBUF         (TCP_SKB_MIN_TRUESIZE * 2)
#define TCP_SKB_MIN_TRUESIZE    (2048 + SKB_DATA_ALIGN(sizeof(struct
sk_buff)))

-> 2 * (2048 + 256) = 4608  given current sk_buff overhead (that might
change in linux 5.4 ... )

But again if your sysctl allows to set a value below SOCK_MIN_SNDBUF,
that might be a problem, because stack could have a hidden bug for very
small values of sndbuf/rcvbuf. 







Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ