From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from userp1040.oracle.com ([156.151.31.81]:42372 "EHLO userp1040.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751611AbcDUOCH (ORCPT ); Thu, 21 Apr 2016 10:02:07 -0400 Subject: Re: stable-security kernel updates To: Greg KH References: <5717DD8A.4000707@oracle.com> <571876AB.2060106@suse.cz> <20160421071157.GC9359@1wt.eu> <5718B92B.3080105@oracle.com> <20160421123631.GA19248@kroah.com> Cc: Willy Tarreau , Jiri Slaby , LKML , stable , lwn@lwn.net From: Sasha Levin Message-ID: <5718DD39.40808@oracle.com> Date: Thu, 21 Apr 2016 10:01:29 -0400 MIME-Version: 1.0 In-Reply-To: <20160421123631.GA19248@kroah.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Sender: stable-owner@vger.kernel.org List-ID: On 04/21/2016 08:36 AM, Greg KH wrote: > On Thu, Apr 21, 2016 at 07:27:39AM -0400, Sasha Levin wrote: >> Hey Willy, >> >> On 04/21/2016 03:11 AM, Willy Tarreau wrote: >>> This illustrates exactly what I suspected would happen because that's the >>> same trouble we all face when picking backports for our respective trees >>> except that since the selection barrier is much higher here, lots of >>> important ones will be missing >> >> Right. I fully agree that there will be important security commits that'll >> get missed, whether because they were missed in the stable selection or >> the stable-security selection. >> >> I'd like to point out again that updating the entire stable tree is the >> preferable way to patch against security (and non-security) issues. > > s/preferable/only/ :) Really? Even though as I showed updating your stable tree religiously would still leave you vulnerable to "ancient" privesc exploits? If anything, the *only* way is updating the entire kernel tree. >> The >> stable-security tree is a best-effort solution to provide a stop-gap in >> between said stable tree updates. > > What are you "stop-gapping" then? The 7-10 days between stable > releases? In a perfect world where everyone has a team of kernel hackers on hand reviewing stable commits, verifying the resulting kernel doesn't regress their product, and fixes existing regressions for their product it might be 7-10 days. In the real world, this process takes much longer. Doing a full rebase of the kernel tree is a much more costly process than cherry picking a handful of security commits. Thanks, Sasha