linux-kernel - Re: [PATCH] nextfd(2)

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:	Wed, 11 Apr 2012 11:11:55 -0700
From:	"H. Peter Anvin" <hpa@...or.com>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
CC:	KOSAKI Motohiro <kosaki.motohiro@...il.com>,
	Alexey Dobriyan <adobriyan@...il.com>,
	akpm@...ux-foundation.org, viro@...iv.linux.org.uk,
	drepper@...il.com, linux-kernel@...r.kernel.org,
	linux-fsdevel@...r.kernel.org
Subject: Re: [PATCH] nextfd(2)

On 04/11/2012 11:04 AM, Linus Torvalds wrote:
> On Wed, Apr 11, 2012 at 10:58 AM, H. Peter Anvin <hpa@...or.com> wrote:
>>
>> But it still has the same braindamage: one system call per loop
>> invocation, and we can do better.  I would much rather see fdwalk() in SUS.
> 
> Why would we bother to do better?
> 
> System calls are cheap, and usually you actually do want to do
> something about the fd, so you actually want to iterate over them.
> 
> I'd much rather have simple cheap interfaces than anything else. If
> SuS has a F_NEXT fcntl, let's just do that thing. Much simpler than
> doing something more complex and then just having to emulate the
> simple thing in user space anyway.
> 
> If a standard interface exists, we should just use it.
> 

I went back and looked at the post, and also the discussion on the SUS
mailing list.

The proposal for FD_NEXT was rejected with some serious vitriol.

fdwalk() was considered just more palatable since there is an existing
implementation (in Solaris) and since it might be possible to provide a
way to hide specific fds from fdwalk(), but a much bigger issue raised
is that *ALL* of these interfaces are inherently broken.  Closing random
file descriptors is:

a) inherently racy in a multithreaded environment;
b) unsafe because there might be file descriptors used by libc itself.

Instead, from the resolution text:

> Therefore, the rest of this proposal seeks to document the problem
> with closing arbitrary file descriptors, and a new bugid will be
> opened to propose standardizing some recent interfaces and interface
> extensions first appearing in Linux (new interfaces such as pipe2( ),
> accept4( ), mkostemps( ), ..., and extensions like fopen(,"we")) to
> guarantee the atomic creation of file descriptors with the cloexec
> bit already set, as was already done in the standard with O_CLOEXEC
> in open( ) and F_DUPFD_CLOEXEC in fcntl( ). See also 0000368 for
> a related proposal to require CLOEXEC on hidden descriptors.

I say we ask the new glibc people to provide fdwalk() since it already
has an implementation history (and because it can be implemented without
new system calls, thereby working on old kernels), but the *big*
takeaway from this is that if there is way to create a file descriptor
so that it doesn't have O_CLOEXEC set from the very beginning, *that* is
what we need to fix.

	-hpa
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/