linux-kernel - Re: Syslets, Threadlets, generic AIO support, v6

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <alpine.LFD.0.98.0705301254210.26602@woody.linux-foundation.org>
Date:	Wed, 30 May 2007 13:00:30 -0700 (PDT)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Davide Libenzi <davidel@...ilserver.org>
cc:	Ingo Molnar <mingo@...e.hu>, Ulrich Drepper <drepper@...hat.com>,
	Jeff Garzik <jeff@...zik.org>,
	Zach Brown <zach.brown@...cle.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Arjan van de Ven <arjan@...radead.org>,
	Christoph Hellwig <hch@...radead.org>,
	Andrew Morton <akpm@....com.au>,
	Alan Cox <alan@...rguk.ukuu.org.uk>,
	Evgeniy Polyakov <johnpol@....mipt.ru>,
	"David S. Miller" <davem@...emloft.net>,
	Suparna Bhattacharya <suparna@...ibm.com>,
	Jens Axboe <jens.axboe@...cle.com>,
	Thomas Gleixner <tglx@...utronix.de>
Subject: Re: Syslets, Threadlets, generic AIO support, v6

On Wed, 30 May 2007, Davide Libenzi wrote:
> 
> Here I think we are forgetting that glibc is userspace and there's no 
> separation between the application code and glibc code. An application 
> linking to glibc can break glibc in thousand ways, indipendently from fds 
> or not fds. Like complaining that glibc is broken because printf() 
> suddendly does not work anymore ;)

No, Davide, the problem is that some applications depend on getting 
_specific_ file descriptors.

For example, if you do

	close(0);
	.. something else ..
	if (open("myfile", O_RDONLY) < 0)
		exit(1);

you can (and should) depend on the open returning zero.

So library routines *must not* open file descriptors in the normal space.

(The same is true of real applications doing the equivalent of

	for (i = 0; i < NR_OPEN; i++)
		close(i);

to clean up all file descriptors before doing something new. And yes, I 
think it was bash that used to *literally* do something like that a long 
time ago.

Another example of the same thing: people open file descriptors and know 
that they'll be "dense" in the result, and then use "select()" on them.

So it's true that file descriptors can't be used randomly by the standard 
libraries - they'd need to have some kind of separate "private space".

Which *could* be something as simple as saying "bit 30 in the file 
descriptor specifies a separate fd space" along with some flags to make 
open and friends return those separate fd's. That makes them useless for 
"select()" (which assumes a flat address space, of course), but would be 
useful for just about anything else.

		Linus
-
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/