Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752912AbcDUOyZ (ORCPT ); Thu, 21 Apr 2016 10:54:25 -0400 Received: from mail-wm0-f67.google.com ([74.125.82.67]:33329 "EHLO mail-wm0-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751654AbcDUOyX (ORCPT ); Thu, 21 Apr 2016 10:54:23 -0400 Subject: Re: stable-security kernel updates To: Sasha Levin , LKML , stable References: <5717DD8A.4000707@oracle.com> <571876AB.2060106@suse.cz> <5718B57D.4000504@oracle.com> <5718C0B8.8010609@suse.cz> <5718DB3F.5020107@oracle.com> Cc: lwn@lwn.net From: Jiri Slaby Message-ID: <5718E997.9030609@suse.cz> Date: Thu, 21 Apr 2016 16:54:15 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <5718DB3F.5020107@oracle.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="UF9cUcC42QApbDXifuJCBbFWmSG9m1i1e" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 6418 Lines: 181 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --UF9cUcC42QApbDXifuJCBbFWmSG9m1i1e Content-Type: multipart/mixed; boundary="Bb10CqOmvbLf7D3WjcsIvndeQVLXxsPm3" From: Jiri Slaby To: Sasha Levin , LKML , stable Cc: lwn@lwn.net Message-ID: <5718E997.9030609@suse.cz> 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> In-Reply-To: <5718DB3F.5020107@oracle.com> --Bb10CqOmvbLf7D3WjcsIvndeQVLXxsPm3 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 04/21/2016, 03:53 PM, Sasha Levin wrote: >> Pardom my ignorance, how can you actually be sure? >=20 > I'm not, same way you can't be sure about your stable patch selection e= ither. I repeat I am not doing any selection. Patches are not included iff they do not apply and I am not confident enough to backport them. In that case, a FAILED message is sent to the authors. And when the authors don't care about that, the patch is not included. > A commit that may not look to you like stable material might turn out t= o be one, > so how is this different for stable-security? I do not select. > "immediately" is a strong word. Right now they won't update at all, so = even > if they take a month to update that's better than the current state. >=20 > I'm not trying to replace the stable trees, I'm trying to help users wh= o don't > update the stable tree that often to at least receive critical fixes in= between > those updates. And that's the point. I doubt you can separate patches to critical fixes and the others. >>> So I've also ended up auditing the 3.12 for missing CVE fixes and the= se >>> ones ended up being at the top of the list. Could you explain why the= y >>> are not in the 3.12 stable tree (and as a result can't get to users o= f >>> the corresponding stable-security tree)? >> >> Sure. They didn't apply or were not marked as stable. In both cases it= >> is the code maintainer responsibility to take care of those. At least = by >> pinging the stable list with SHAs. >=20 > Given this, how can you tell people they should be using your stable tr= ee > 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 tagg= ed > as such. 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. > Those commits fix real bugs and by not shipping them users are given a = false > sense of security by just updating the stable tree rather than the enti= re > kernel tree. Updating versions is painful, because new features and code refactoring introduce bugs. We do not backport those. That's the difference. >>> (CVE-2015-7513) 0185604 KVM: x86: Reload pit counters for all channel= s when restoring state >> >> This was not evaluated for SLE12 yet. >=20 > This is an almost half a year old vulnerability that allows guests to c= rash > KVM hosts; something I'd consider quite critical these days. >=20 > This sort of thing is something that might encourage users not to follo= w the > stable tree at all. If updating the stable tree won't fix these sort of= critical > issues, then why bother at all? Well, if that's so critical, why is there no trace on the stable list about it to be applied to all trees? I indeed committed it into 3.12 already. > I'd be happy to set clearer guidelines for what I consider a security > fix if that's the concern here? Yes, please. >> Fourth, naturally, there is a lot of patches missing in the net flowin= g >> in the large sea of patches. But given your count of patches, you have= ~ >> 2 times higher chance to miss something important. >=20 > I do? Per the definition of stable-security, I only have to select them= > from the ones you already selected. So while I have to look through ~50= > commits per version you need to look at hundreds. But yet, you missed some important fixes in a single release. > You're way more likely than me to miss a commit that was supposed to be= > in stable, Naturally, see above. I am not doing filtering though. I include everything which fixes a bug and I am aware of. > than me missing something that had to go into stable-security. Doing any filtering on patches that somebody proposed to be in stable is anything but -security. If people feel that's too much updates, they should run some sort of BSD or something. Anyway, it's nonsense to review all the patches and pretend to understand the code well enough to decide whether the patches are OK or not. It's bullshit. That's the very reason why any selection won't ever work. And provided we run stable trees on all our products with no dedicated people to stable patches (except me collecting 3.12 and randomly applying stable patches) and we saw only little bugs introduced by stable over the past decade, I do not believe they chose the right approach. Stable really pays off as it stays even though the process could be improved in many ways as was discussed many times, of course. thanks, --=20 js suse labs --Bb10CqOmvbLf7D3WjcsIvndeQVLXxsPm3-- --UF9cUcC42QApbDXifuJCBbFWmSG9m1i1e 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 iQIcBAEBCAAGBQJXGOmYAAoJEL0lsQQGtHBJNGYP/3dnbBroxKPEixTYH1CHIXuD +HFGDPPWVZHznaQuDcX7IOXgRpdvbxSnOrMlWzdR+h5ooFtggdcrxsoZFZJsqBA4 Q4kYqoTMYP0aYvx3QMhPRtCVjWoFlntQbZAc8AVfMBu2Vex3StB79JhwVIqVse0u 28iEuLCAlGeJpCdA06lFZkKi3mmspUX1vEmOSGqF2Km2eyie7SJyT51p4pmZg9n4 edxXH9Q2Sju+GvrVZy/1v5IR4vY7ma6wejz0pIy0eggbPsub8KA60UtiHkWeua/J AMq9KL1MJBtd0ocTpKMZjmCXQRLvHnHuIQXLUpZGu4n1udSLGOsdxogWC2XSy4hq Hm/kqgxGjgN27iUcXb3/PR728uF0D9plS+t9/g6jtmQa2uKMRSkokcTqAVZzSFJA HA98MaTAP85YQYYDA13ZnbQqHx/fsfOddrdDFwagZX0LaA2roVlszx50E5gyb82o Z3TbTOwqtQQWsn9hZA2/1IOCClGP1CbsYtTmOFnYpWUgAFsY4caVg8k7gZDs3vuh AX5swC0xTKPqfPtd78q8sjzt4yAok0/EyZNWvYqMNRbw108S+SdG/wuRSe1PtpKS SLWymCMLeEfhV77vvAsnTOPSOfp3j709k53uI7FEZBzRT3goZ2R88GDfcLzxUJoV aPFiJu+UaMydmXA3prPX =z9Tq -----END PGP SIGNATURE----- --UF9cUcC42QApbDXifuJCBbFWmSG9m1i1e--