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: <18027.39295.464374.371664@cargo.ozlabs.ibm.com>
Date:	Sun, 10 Jun 2007 16:26:07 +1000
From:	Paul Mackerras <paulus@...ba.org>
To:	Davide Libenzi <davidel@...ilserver.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

Davide Libenzi writes:

> > Why must everything that makes things a bit simpler and more
> > predictable for application programmers be called a "mistake"?
> 
> Because if you give guarantees on something, ppl start using such 
> guarantee in the wrong way. Kyle's email summarizes it.

OK, my question/protest was a bit terse.

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

If you don't think we should be bound by POSIX, then you are perfectly
free to go off and write your own research kernel with whatever
interface you want, and no programs available to run on it. :)

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