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: Windows password security audit tool. GUI, reports in PDF.

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

Date:	Thu, 31 Jul 2008 12:44:04 -0700 (PDT)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Dmitry Torokhov <dmitry.torokhov@...il.com>
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, 31 Jul 2008, Dmitry Torokhov wrote:
> 
> Does it have to be papered over in the kernel though?

Yes. It's how we have worked. Asking people to upgrade big core programs 
is not reasonable.

Think of it this way: we absolutely _want_ people to run the latest 
kernel. We want it for their own sake (security etc fixes), but we want it 
even more for *our* own sake (testing, fixes etc).

And if we want to encourage people to upgrade their kernel very 
aggressively (and we absolutely do!), then that means that we have to also 
make sure it doesn't require them upgrading anything else.

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

There are gray areas, yes. For example, timing changes do mean that a new 
kenrel can easily break a program that used to work. We cannot handle 
_everyting_. 

But when the ABI in question is some very specific one, that some 
important program uses (even if the "uses" is "misuses") then it really 
isn't a gray area any more.

And quite frankly, the ABI was apparently pretty bad to begin with, if 
user space got an array back but didn't get to specify the size. So you 
may want to say that user space was broken, but on the other hand, it's 
equally arguable that the ABI was crap.

(Which is something you can pretty much take for granted with ioctl's, of 
course. DO NOT CHANGE IOCTL'S. EVER!)

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

You ignore the obvious choice, which is how we _usually_ do it:

 - help fix up the userspace driver regardless

 - a year down the line, maybe breakage will be a non-issue.

 - but at least _think_ about the fact that yes, most ioctl interfaces are 
   pure and utter sh*t, and the problem was probably not so much the user 
   space driver as the crap interface to begin with!

and discuss whether KEY_MAX really needs to be changed that much. I 
suspect that the change was done without even realizing just how painful 
it was, and that if you look at the original reason for it with the 
hindsight of knowing that it was painful, maybe it wasn't that critical to 
do it after all?

		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/