Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752931AbcDUTdP (ORCPT ); Thu, 21 Apr 2016 15:33:15 -0400 Received: from userp1040.oracle.com ([156.151.31.81]:19471 "EHLO userp1040.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752114AbcDUTdO (ORCPT ); Thu, 21 Apr 2016 15:33:14 -0400 Subject: Re: stable-security kernel updates To: Jiri Slaby , LKML , stable References: <5717DD8A.4000707@oracle.com> <571876AB.2060106@suse.cz> <5718B57D.4000504@oracle.com> <5718C0B8.8010609@suse.cz> <5718DB3F.5020107@oracle.com> <5718E997.9030609@suse.cz> Cc: lwn@lwn.net From: Sasha Levin Message-ID: <57192AEA.2060004@oracle.com> Date: Thu, 21 Apr 2016 15:32:58 -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: <5718E997.9030609@suse.cz> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="IxpcV75TTSxIMuQWEFWu3PRer5QbmlNwk" X-Source-IP: aserv0022.oracle.com [141.146.126.234] Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 5388 Lines: 153 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --IxpcV75TTSxIMuQWEFWu3PRer5QbmlNwk Content-Type: multipart/mixed; boundary="Eje769h3cDIfTKdXPrgNDNlENtLx7JBVX" From: Sasha Levin To: Jiri Slaby , LKML , stable Cc: lwn@lwn.net Message-ID: <57192AEA.2060004@oracle.com> Subject: Re: stable-security kernel updates References: <5717DD8A.4000707@oracle.com> <571876AB.2060106@suse.cz> <5718B57D.4000504@oracle.com> <5718C0B8.8010609@suse.cz> <5718DB3F.5020107@oracle.com> <5718E997.9030609@suse.cz> In-Reply-To: <5718E997.9030609@suse.cz> --Eje769h3cDIfTKdXPrgNDNlENtLx7JBVX Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 04/21/2016 10:54 AM, Jiri Slaby wrote: > On 04/21/2016, 03:53 PM, Sasha Levin wrote: >> I'm not trying to replace the stable trees, I'm trying to help users w= ho don't >> update the stable tree that often to at least receive critical fixes i= n between >> those updates. >=20 > And that's the point. I doubt you can separate patches to critical fixe= s > and the others. Build fixes? new device IDs? quirks? We can agree that it's not security.= We can also agree that there are commits that clearly pose no security ri= sk, right? =46rom the latest 3.18 release, stuff like: 07508eb iw_cxgb3: Fix incorrectly returning error on success 983cabe iio: pressure: mpl115: fix temperature offset sign c8d69b6 sched: Fix crash in sched_init_numa() etc' Obviously don't pose a security risk. If we agree on that, then we've left with ~30% of the original tree, wher= e the security status is questionable. As I've mentioned, I'd be happy to discu= ss the criteria for what we consider a "security" fix. Maybe it'll be all 30= %, maybe less. >> Given this, how can you tell people they should be using your stable t= ree >> rather than updating the kernel as a whole? The 3.12 tree is missing a= big >> chunk of commits that are stable material even though they weren't tag= ged >> as such. >=20 > That's why more than one stable tree is released for every kernel. It's= > growing. If you know about any more issues, share with us, they will be= > fixed. If this is what you expect me to do, why was your first response on this stable-security release was "I suggest nobody uses that kernel."? When I started working on the 3.18 stable tree, it was easy to see that t= here is a problem maintaining these type of trees. Some commits were never added,= some backported incorrectly, some reverted on one tree but not the others, and= so on. Instead of bashing Greg and other maintainers that the stable tree is a d= umb idea that can never work ("how can you decide what's a real fix and what's not= ?") I went to write a set of tools that was supposed to help maintainers build corre= ct stable trees and validate their correctness versus other stable trees (available= here, for quite a while: https://git.kernel.org/cgit/linux/kernel/git/sashal/stable= -tools.git/). I've never received a comment on it, or heard of anyone using it, even th= ough it could have easily caught so many issues with each tree (such as the CVEs = I've copied earlier - this is how I dug them up). The stable tree idea was born as a result of real need by users/customers= /projects. It's implementation isn't perfect, but we're all working together on maki= ng it better: catching bugs, improving automation and reviewing each others work. The stable-security idea was also a result of the same need. I didn't mak= e it up just so I'll have more stuff to maintain, I started it because users simp= ly weren't following the stable tree after a certain point. I can wave my finger at = them all I want, I can even ask Greg to wave his finger at them as well, but it's = not going to change them; they still will be running months old kernel in productio= n, being exposed to same nasty bugs. If you have a better way of solving this I'm all ears. I'd happily change= stable-security if you have a plan of making it work better somehow. However, if thats no= t the case, can we work together or improving it? Or at least not be sending each oth= er inflammatory mails about missing or not missing commits? Thanks, Sasha --Eje769h3cDIfTKdXPrgNDNlENtLx7JBVX-- --IxpcV75TTSxIMuQWEFWu3PRer5QbmlNwk Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJXGSrrAAoJEN6mb/eXdyzcRXEQAKayTNqd8bfXzbLmp2qT7VrC SjBtI+sA7i1n4ZMchP21Oe8oi9vJAtnyLpSqpmWtz0B20s2yXZv2QRUSjUkkWWJa zojySxdnN8g/fbCJgDewHpZqqsz9exVLBJmhxzO2mCpppsPBz0X7FVvI2lqYmdhf hcuPxxxUzLZP+fSQUb/tsKdNmyvnd2CoO2tu4btOHzdAvpfIF/+nZbhC7nAGJ8gP sB0XvH71X0nxLErlqyUoLS+36vDI6i2Le4IxVSmexJOyt/AsQnBF9fIZIPGNSxM0 +57bgQObKa2MfNsxaG5w5aXb91wbUrf+tSgc1xfdewzh1QGEiiFuX7kMLMy3l4AZ I4+Hpl8lxY3B2vXJEyn4b4GdEvMQkKiA7yIsuF+oSsJ0DcjE4QBVQf6BnaD+wmFq EaTtm2t+nIhvV5hlIbXMPZ8uHoqx8TT+osl7jqJoCtTz+tceAfR3sSmd3Ge0uZ2p FExL1ZXZLREnlkOUk9bpq/N93Cc6OTqMp2yDi/mV9epYQ+DQVSezqK6aKUBqe1UU 4HVPWvRrcuqKx8dV4yUolxtQ7KTxeQStI9wavOewmdsoWqkIZ9JIwhxn4JBkpoPn FwLLhArG2pCPm3GDM4BsPIvjDP8BbTVgNz+wJa6SekWxPQWmAi/0TpQlDMhho/z2 zNKB/xkBUA8fWsAH62ul =3Swr -----END PGP SIGNATURE----- --IxpcV75TTSxIMuQWEFWu3PRer5QbmlNwk--