Re: stable-security kernel updates

[Jiri Slaby]

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: signature.asc
Description: OpenPGP digital signature