Subject: Re: [ANNOUNCE] linux-stable security tree
To: Greg KH <gregkh@linuxfoundation.org>
References: <570BE4A5.20200@oracle.com> <20160411184148.GA23140@kroah.com>
Cc: LKML <linux-kernel@vger.kernel.org>, stable <stable@vger.kernel.org>,
        lwn@lwn.net
From: Sasha Levin <sasha.levin@oracle.com>
Message-ID: <570BF3DD.2060900@oracle.com>
Date: Mon, 11 Apr 2016 14:58:37 -0400
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101
 Thunderbird/38.6.0
MIME-Version: 1.0
In-Reply-To: <20160411184148.GA23140@kroah.com>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 8bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 3098
Lines: 73

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.

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

> Good luck with this, personally, I think projects should just take the
> stable tree as really, it's not that much churn at all, given the % of
> the mainline tree.


Thanks,
Sasha