Message-ID: <35746.1308166946@turing-police.cc.vt.edu>
Date:	Wed, 15 Jun 2011 15:42:26 -0400
From:	Valdis.Kletnieks@...edu
To:	pageexec@...email.hu
Cc:	Ingo Molnar <mingo@...e.hu>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Andi Kleen <andi@...stfloor.org>,
	Andy Lutomirski <luto@....edu>, x86@...nel.org,
	Thomas Gleixner <tglx@...utronix.de>,
	linux-kernel@...r.kernel.org, Jesper Juhl <jj@...osbits.net>,
	Borislav Petkov <bp@...en8.de>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Arjan van de Ven <arjan@...radead.org>,
	Jan Beulich <JBeulich@...ell.com>,
	richard -rw- weinberger <richard.weinberger@...il.com>,
	Mikael Pettersson <mikpe@...uu.se>,
	Brian Gerst <brgerst@...il.com>,
	Louis Rilling <Louis.Rilling@...labs.com>
Subject: Re: [PATCH v5 9/9] x86-64: Add CONFIG_UNSAFE_VSYSCALLS to feature-removal-schedule

On Tue, 14 Jun 2011 02:48:35 +0200, pageexec@...email.hu said:
> > It makes it distinctly *easier*: people will update their systems
> > based on a list of say 10 CVEs that affect them, totally blind to the
> > 100+ other bugs that may (or may not) have an effect on them. 
>
> 'people' are not updating their systems based on any list. 'people' update their
> systems based on what their kernel supplier (vendor/distro/company's internal
> team/etc) provides them with (there's an extreme minority of users who build
> their own kernels of the latest vanilla tree).
>
> now the big question becomes whether these suppliers are helped or obstructed by
> your policy of covering up security fixes. given that pretty much none of them
> supports the latest vanilla tree, not even -stable, it means that in order to
> release new kernels they'll have to backport fixes. fixes that they don't even
> know they should be backporting because of your covering them up. so what happens
> is that everyone has to read every commit and do his best estimate whether it's
> worthy of backporting or not (notice the waste of duplicated effort). don't you
> think they could spend more time on finding actually important fixes if they
> could skip over the already known ones and just backport them?

You point out that "people" don't do updates based on the list - but then
recommend that *vendors* base their updates on the same list for the same
reasons. So instead of a user at risk, now it's every customer of a vendor at
risk, because the *vendor* will just cherry-pick the fixes labelled "security".
The vendor *still* has to go through the entire pile of fixes *anyhow*, because
we already *know* that we may fail to recognize that a fix is
security-relevant. So cherry-picking "security" is doing the customers a
dis-service.

Second, the vendor's engineers *still* have to go through all the fixes
*anyhow*, because in the *real world*, "security" is *not* the only thing -
it's *one small piece*.  A vendor's customers don't really care if the vendor
includes a fix for some hard-to-exploit kernel hole if the vendor fails to ship
the patch that keeps the fiberchannel controller card from locking up the
system, or the patch that makes MySQL not SEGV, or the patch that fixes dropped
characters on the tty line their data aquisition system uses, or the patch that
keeps the filesystem from corrupting directories because of a bad refcount.

If the system *does not work*, customers *don't care* about its security.  And
you're going to have a hard time if you keep trying to sell your "security is
everything" viewpoint to people who have to support systems where security is
only one piece of it.


Content of type "application/pgp-signature" skipped

Powered by blists - more mailing lists