linux-kernel - Re: linux-next: Tree for July 30

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]

Date:	Thu, 31 Jul 2008 15:24:02 -0400
From:	Dmitry Torokhov <dmitry.torokhov@...il.com>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	"Rafael J. Wysocki" <rjw@...k.pl>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Bartlomiej Zolnierkiewicz <bzolnier@...il.com>,
	Stephen Rothwell <sfr@...b.auug.org.au>,
	linux-next@...r.kernel.org, LKML <linux-kernel@...r.kernel.org>,
	linux-input@...r.kernel.org
Subject: Re: linux-next: Tree for July 30

On Thu, Jul 31, 2008 at 12:10:40PM -0700, Linus Torvalds wrote:
> 
> 
> On Thu, 31 Jul 2008, Dmitry Torokhov wrote:
> > > 
> > > Well, we're not supposed to break user space that we used to work with, even
> > > if it is known to be buggy.
> > 
> > No, I am sorry. We are not supposed to break userspace ABI, but that
> > is it. Can you vouch that 2.6.25 did not break a single userspace
> > program out there?
> 
> Dmitry - irrelevant. If we know of breakage, then that is a FACT, and it's 
> a regression, and it needs to be fixed.

Does it have to be papered over in the kernel though?

> 
> Trying to say "there might be _other_ breakage that we don't even know of" 
> does not change the situation ONE LITTLE BIT!
> 
> Don't you see how stupid that approach is? You're basically trying to make 
> excuses for known breakage by saying that there might be _other_ breakage 
> that we don't know about? Why the _hell_ do you think that is an excuse at 
> all?

We can only guarantee one thing - ABI. And that is kept intact. But I
literally have no idea if a kernel breaks a random program out there
that happens to have a bug.

> 
> > >  Many people use the older user space on their
> > > test systems which are not practical to upgrade.
> > 
> > I don't understand this - it is expected that everyone jumps and
> > upgrades their kernels with ease but updating broken userspace
> > bits is super-hard...
> 
> You're missing the point.
> 
> People are supposed to be able to upgrade things _independently_. It's not 
> about "you're supposed to be able to upgrade the kernel, but not upgrade 
> user space". It's about "you shouldn't evemn have to _worry_ about it.
> 
> > > IOW, if the change responsible for this makes it to the mainline kernel, it
> > > will be considered as a regression.
> > 
> > Like I said, I don't agree.
> 
> Sorry, but you're simply wrong.
> 
> If somebody has the commit that broke user space, that commit will be 
> _reverted_ unless it's fixed. It's that simple. The rules are: we don't 
> knowingly break user space. 
>

We have 3 options now:

1. Never change KEY_MAX and dont add any new key definitions.
2. Introduce a new ioctl and have all wel-behaving programs rewritten
   to support it.
3. Fix userspace driver (patch is available).

Gioventhe fact that I wanted that change to go when .28 opens and it
will really hit users in 6+ months I'd still like to have 3.
 
-- 
Dmitry
--
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/