linux-kernel - Re: [patch 7/8] fdmap v2

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]

Message-Id: <463C79D8-88CB-492A-96FD-10C10D16C4B6@mac.com>
Date:	Sat, 9 Jun 2007 10:38:55 -0400
From:	Kyle Moffett <mrmacman_g4@....com>
To:	Paul Mackerras <paulus@...ba.org>
Cc:	Davide Libenzi <davidel@...ilserver.org>,
	Alan Cox <alan@...rguk.ukuu.org.uk>,
	Theodore Tso <tytso@....edu>,
	Ulrich Drepper <drepper@...hat.com>,
	Eric Dumazet <dada1@...mosbay.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Ingo Molnar <mingo@...e.hu>
Subject: Re: [patch 7/8] fdmap v2 - implement sys_socket2

On Jun 09, 2007, at 01:41:42, Paul Mackerras wrote:
> Davide Libenzi writes:
>
>> The only reason we use a floating base, is because Uli preferred  
>> to have non-exactly predictable fd allocations. There no reason of  
>> re-doing the same POSIX mistake all over again:
>
> Why must everything that makes things a bit simpler and more  
> predictable for application programmers be called a "mistake"?

1)  Linear FD allocation makes it IMPOSSIBLE for libraries to  
reliably use persistent FDs behind an application's back.  For  
example, this code sequence should almost always be OK: (except when  
calling into a library specifically to open a file or socket)

close(0);
some_library_function();
fd = open("some_file", O_RDWR);
/* fd == 0 here */

2)  Another common code example which causes problems:

int i;
for (i = 0; i < NR_OPEN; i++)
	if (!fd_is_special_to_us(i))
		close(i);

Note that this is conceptually buggy, but occurs in several major C  
programming books, most of the major shells, and a lot of other  
software to boot.

3) In order to allocate new FDs, the kernel has to scan over a  
(potentially very large) bitmap.  A process with 100,000 fds (not  
terribly uncommon) would have 12.5kbyte of FD bitmap and would trash  
the cache every time it tried to allocate an FD.

You can't even hope to use persistent library FDs with these  
problems, and they even cause problems with servers using lots of  
FDs.  Introducing another linear FD space will just make this sort of  
stuff happen ALL OVER AGAIN.

If you want to make things reproducible, you could have an option  
where the "random" algorithm is just pseudo-linearly allocated FDs  
(no bitmap search) XORed with a boot-time constant either randomly- 
generated or set in the boot args.  That way the people interested in  
maximum security or stress testing can use completely randomized  
numbers and the people who need reproducibility can get that too,  
*without* having the same linear FD allocation problems all over  
again.  The fundamental problem is that a series of numbers  
increasing linearly from X (especially where X == 0) are used as  
meaningful data by lazy programmers, instead of just as a cookie.  By  
nonlinearizing the data, even just a little, that becomes unlikely to  
occur.  It also forces programmers to use FDs correctly and prevents  
problems like this in the future.

Cheers,
Kyle Moffett
-
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/