Date: Mon, 11 Apr 2016 13:09:04 -0700
From: Greg KH <gregkh@linuxfoundation.org>
To: Sasha Levin <sasha.levin@oracle.com>
Cc: LKML <linux-kernel@vger.kernel.org>, stable <stable@vger.kernel.org>,
        lwn@lwn.net
Subject: Re: [ANNOUNCE] linux-stable security tree
Message-ID: <20160411200904.GB24106@kroah.com>
References: <570BE4A5.20200@oracle.com>
 <20160411184148.GA23140@kroah.com>
 <570BF3DD.2060900@oracle.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <570BF3DD.2060900@oracle.com>
User-Agent: Mutt/1.6.0 (2016-04-01)
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 4339
Lines: 96

On Mon, Apr 11, 2016 at 02:58:37PM -0400, Sasha Levin wrote:
> On 04/11/2016 02:41 PM, Greg KH wrote:
> > On Mon, Apr 11, 2016 at 01:53:41PM -0400, Sasha Levin wrote:
> >> Hi all,
> >>
> >>
> >> I'd like to announce the linux-stable security tree project. The purpose
> >> is to create a derivative tree from the regular stable tree that would
> >> contain only commits that fix security vulnerabilities.
> > 
> > And how are you going to define "security vulnerabilities"?
> 
> In general, anything that qualified for a CVE plus anything exploitable
> by a local unprivileged user.
> 
> > Also, what kernel branches are you going to do this for, and for how
> > long?
> 
> All active -stable kernels, for as long as those corresponding kernels
> are supported. This isn't a brand new tree, but is a subset of it's
> corresponding -stable tree.
> 
> >> Quite a few users of the stable trees pointed out that on complex deployments,
> >> where validation is non-trivial, there is little incentive to follow the
> >> stable tree after the product has been deployed to production. There is no
> >> interest in "random" kernel fixes and the only requirements are to keep up
> >> with security vulnerabilities.
> > 
> > "random" is in the eye of the beholder :)
> 
> It's not "random" for us building the tree, but it's very much "random"
> for the users for see fixes for drivers they've never even heard of before.

Then why would it matter if they pulled the tree or not?  How are you
going to judge which driver fixes to take and which not to?  Why not
take them all if they fix bugs?

> > Everyone's definition of that is different, I think you will find that
> > it's best to just do the full tree, or pick and choose what you want
> > from the tree based on your own needs, instead of trying to judge what
> > those needs are.
> 
> It would probably be ideal if everyone could cherry pick correctly only and
> all the commits they require, but reality is quite far from this ideal, which
> is why we have things like the stable trees - to simplify the process.
> 
> >> Given this, a few projects preferred to delay important kernel updates, and
> >> a few even stopped updating the tree altogether, exposing them to critical
> >> vulnerabilities.
> > 
> > What projects are those?  Is it really that hard to take the current
> > stable trees for these projects?  Why is this tree going to somehow be
> > easier?
> 
> I can give you an example offlist (mostly because I don't want to start listing
> projects in production with outdated kernels who could use security updates).
> 
> >> This project provides an easy way to receive only important security commits,
> >> which are usually only a few in each release, and makes it easy to incorporate
> >> them into existing projects.
> > 
> > Define "important".  Now go and look at the tty bug we fixed that people
> > only realized was "important" 1 1/2 years later and explain if you
> > would, or would not have, taken that patch in this tree.
> 
> Probably not, but I would have taken it after it received a CVE number.
> 
> Same applies to quite a few commits that end up in stable - no one thinks
> they're stable material at first until someone points out it's crashing
> his production boxes for the past few months.

Yes, but those are rare, what you are doing here is suddenly having to
judge if a bug is a "security" issue or not.  You are now in the
position of trying to determine "can this be exploited or not", for
every commit, and that's a very hard call, as is seen by this specific
issue.

If you only take things you "know" are issues, well, you miss lots of
fixes that were really security things but only found out later, so
people have to scamble to fix their kernels much faster than they needed
to.

Putting up a tree like this isn't going to cause people to update their
trees any quicker.  If they haven't been doing it now, they aren't going
to do it with this tree, as their workloads don't allow them to take
updated kernel trees.

In short, it's not the fact that we have stable trees that are "too big"
for them to take, it's the fact that they just can't take and test
updates properly.  They need to fix their processes, it's not a
deficiency on our side from everyone I have talked to, including the
example you gave me off-list :)

good luck!

greg k-h