stable.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jiri Slaby <jslaby@suse.cz>
To: Sasha Levin <sasha.levin@oracle.com>,
	LKML <linux-kernel@vger.kernel.org>,
	stable <stable@vger.kernel.org>
Cc: lwn@lwn.net
Subject: Re: stable-security kernel updates
Date: Thu, 21 Apr 2016 16:54:15 +0200	[thread overview]
Message-ID: <5718E997.9030609@suse.cz> (raw)
In-Reply-To: <5718DB3F.5020107@oracle.com>


[-- Attachment #1.1: Type: text/plain, Size: 4627 bytes --]

On 04/21/2016, 03:53 PM, Sasha Levin wrote:
>> Pardom my ignorance, how can you actually be sure?
> 
> I'm not, same way you can't be sure about your stable patch selection either.

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 to 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.
> 
> I'm not trying to replace the stable trees, I'm trying to help users who 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 these
>>> ones ended up being at the top of the list. Could you explain why they
>>> are not in the 3.12 stable tree (and as a result can't get to users of
>>> 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.
> 
> Given this, how can you tell people they should be using your stable tree
> 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 tagged
> 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 entire
> 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 channels when restoring state
>>
>> This was not evaluated for SLE12 yet.
> 
> This is an almost half a year old vulnerability that allows guests to crash
> KVM hosts; something I'd consider quite critical these days.
> 
> This sort of thing is something that might encourage users not to follow 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 flowing
>> in the large sea of patches. But given your count of patches, you have ~
>> 2 times higher chance to miss something important.
> 
> 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,
-- 
js
suse labs


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

  reply	other threads:[~2016-04-21 14:54 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-04-20 19:50 stable-security kernel updates Sasha Levin
2016-04-21  6:43 ` Jiri Slaby
2016-04-21  7:11   ` Willy Tarreau
2016-04-21 11:27     ` Sasha Levin
2016-04-21 12:36       ` Greg KH
2016-04-21 14:01         ` Sasha Levin
2016-04-21 14:12           ` Willy Tarreau
2016-04-21 11:11   ` Sasha Levin
2016-04-21 11:59     ` Jiri Slaby
2016-04-21 12:05       ` Jiri Slaby
2016-04-21 12:39         ` Greg KH
2016-04-21 12:50           ` Willy Tarreau
2016-04-21 13:54           ` Sasha Levin
2016-04-21 14:13             ` Jiri Slaby
2016-04-21 14:19               ` Willy Tarreau
2016-04-21 14:27               ` Sasha Levin
2016-04-21 14:33                 ` Willy Tarreau
2016-04-25 23:14                   ` Ben Hutchings
2016-04-26  4:40                     ` Willy Tarreau
2016-04-21 13:53       ` Sasha Levin
2016-04-21 14:54         ` Jiri Slaby [this message]
2016-04-21 15:50           ` Sasha Levin
2016-04-21 19:32           ` Sasha Levin
2016-04-21 12:26     ` Bjørn Mork
2016-04-21 12:56 ` Willy Tarreau
2016-04-21 14:16   ` Sasha Levin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5718E997.9030609@suse.cz \
    --to=jslaby@suse.cz \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lwn@lwn.net \
    --cc=sasha.levin@oracle.com \
    --cc=stable@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).