netdev - Re: [Bug 106241] New: shutdown(3)/close(3) behaviour is incorrect for sockets in accept(3)

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:	Thu, 22 Oct 2015 22:57:41 +0100
From:	Al Viro <viro@...IV.linux.org.uk>
To:	Casper.Dik@...cle.com
Cc:	Alan Burlison <Alan.Burlison@...cle.com>,
	David Miller <davem@...emloft.net>, eric.dumazet@...il.com,
	stephen@...workplumber.org, netdev@...r.kernel.org,
	dholland-tech@...bsd.org
Subject: Re: [Bug 106241] New: shutdown(3)/close(3) behaviour is incorrect
 for sockets in accept(3)

On Thu, Oct 22, 2015 at 09:51:05PM +0200, Casper.Dik@...cle.com wrote:
> 
> >On Thu, Oct 22, 2015 at 08:24:51PM +0200, Casper.Dik@...cle.com wrote:
> >
> >> The external behaviour atomic; you cannot distinguish the order
> >> between the closing of the original file (and waking up other threads
> >> waiting for a record lock) or changing the file referenced by that newfd.
> >> 
> >> But this not include a global or process specific lock.
> >
> >Interesting...  Do you mean that decriptor-to-file lookup blocks until that
> >rundown finishes?
> 
> For that particular file descriptor, yes.  (I'm assuming you mean the 
> Solaris kernel running down all lwps who have a system in progress on that 
> particular file descriptor).  All other fd to file lookups are not blocked 
> at all by this locking.
> 
> It should be clear that any such occurrences are application errors and 
> should be hardly ever seen in practice.  It is also known when this is 
> needed so it is hardly even attempted.

Ho-hum...  It could even be made lockless in fast path; the problems I see
are
	* descriptor-to-file lookup becomes unsafe in a lot of locking
conditions.  Sure, most of that happens on the entry to some syscall, with
very light locking environment, but... auditing every sodding ioctl that
might be doing such lookups is an interesting exercise, and then there are
->mount() instances doing the same thing.  And procfs accesses.  Probably
nothing impossible to deal with, but nothing pleasant either.
	* memory footprint.  In case of Linux on amd64 or sparc64,
main()
{
	int i;
	for (i = 0; i < 1<<24; dup2(0, i++))	// 16M descriptors
		;
}
will chew 132Mb of kernel data (16Mpointer + 32Mbit, assuming sufficient ulimit -n,
of course).  How much will Solaris eat on the same?
	* related to the above - how much cacheline sharing will that involve?
These per-descriptor use counts are bitch to pack, and giving each a cacheline
of its own...  <shudder>
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html