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: <Pine.LNX.4.64.0706100831530.24724@alien.or.mcafeemobile.com>
Date:	Sun, 10 Jun 2007 08:52:09 -0700 (PDT)
From:	Davide Libenzi <davidel@...ilserver.org>
To:	Paul Mackerras <paulus@...ba.org>
cc:	Alan Cox <alan@...rguk.ukuu.org.uk>, Theodore Tso <tytso@....edu>,
	Ulrich Drepper <drepper@...hat.com>,
	Eric Dumazet <dada1@...mosbay.com>,
	Kyle Moffett <mrmacman_g4@....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 Sun, 10 Jun 2007, Paul Mackerras wrote:

> What I am objecting to is this idea that many kernel developers seem
> to have, that if there is some aspect of the kernel/user API that
> becomes a bit inconvenient for the kernel to implement, then we can
> put the blame on the applications that rely on that aspect, call them
> names such as "legacy", "abuser", "conceptually buggy", "broken",
> etc., and ultimately justify breaking the ABI -- since it's only those
> applications that we have demonised that will be affected, after all.
> 
> In a way your response quoted above illustrates this perfectly.  If we
> give guarantees then people will start relying on them "in the wrong
> way" -- meaning, in any way that later becomes inconvenient to us.
> What next?  Shall we break the guarantee that when read() returns, the
> data is already in the user's buffer?  I'm sure we could improve
> performance if we didn't have to give that guarantee, and after all,
> only old, broken, legacy, conceptually buggy programs would be abusing
> the interface by relying on that. :)

This fds will be out of POSIX definition in any case. They have to be 
based at very high values in any case in order to be useful, and this 
already breaks the POSIX definition of them.



> > This should really be treated as an opaque handle, with no assumption on 
> > its value.
> 
> No.  This is an assertion that you have just conjured up to suit
> yourself, but it is wrong.  It does not reflect either historical UNIX
> practice or what is specified in POSIX.  Application writers are
> perfectly justified in relying on getting the lowest-numbered unused
> file descriptor.

You seem to deny the fact that libraries cannot reliably use fds allocated 
by POSIX rules for internal communication with the kernel. I really don't 
know what to say, if not that we must have a different definition of the 
word "reliable".
Maybe if you go back in the thread and give your solutions, using POSIX 
fds allocation semantics, to the problems that have been exposed, that 
might help understanding.



- Davide


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