Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1383716 > unrolled thread

stable-security kernel updates

Back to article view | Back to linux.kernel

Contents

  stable-security kernel updates Sasha Levin <sasha.levin@oracle.com> - 2016-04-20 22:00 +0200
    Re: stable-security kernel updates Jiri Slaby <jslaby@suse.cz> - 2016-04-21 08:50 +0200
      Re: stable-security kernel updates Willy Tarreau <w@1wt.eu> - 2016-04-21 09:20 +0200
        Re: stable-security kernel updates Sasha Levin <sasha.levin@oracle.com> - 2016-04-21 13:30 +0200
          Re: stable-security kernel updates Greg KH <greg@kroah.com> - 2016-04-21 14:40 +0200
            Re: stable-security kernel updates Sasha Levin <sasha.levin@oracle.com> - 2016-04-21 16:10 +0200
              Re: stable-security kernel updates Willy Tarreau <w@1wt.eu> - 2016-04-21 16:20 +0200
      Re: stable-security kernel updates Sasha Levin <sasha.levin@oracle.com> - 2016-04-21 13:20 +0200
        Re: stable-security kernel updates Jiri Slaby <jslaby@suse.cz> - 2016-04-21 14:10 +0200
          Re: stable-security kernel updates Greg KH <greg@kroah.com> - 2016-04-21 14:40 +0200
            Re: stable-security kernel updates Willy Tarreau <w@1wt.eu> - 2016-04-21 15:00 +0200
            Re: stable-security kernel updates Sasha Levin <sasha.levin@oracle.com> - 2016-04-21 16:00 +0200
              Re: stable-security kernel updates Jiri Slaby <jslaby@suse.cz> - 2016-04-21 16:20 +0200
                Re: stable-security kernel updates Willy Tarreau <w@1wt.eu> - 2016-04-21 16:20 +0200
                Re: stable-security kernel updates Sasha Levin <sasha.levin@oracle.com> - 2016-04-21 16:30 +0200
                  Re: stable-security kernel updates Willy Tarreau <w@1wt.eu> - 2016-04-21 16:40 +0200
                    Re: stable-security kernel updates Ben Hutchings <ben@decadent.org.uk> - 2016-04-26 01:20 +0200
                      Re: stable-security kernel updates Willy Tarreau <w@1wt.eu> - 2016-04-26 06:50 +0200
        Re: stable-security kernel updates Jiri Slaby <jslaby@suse.cz> - 2016-04-21 14:10 +0200
          Re: stable-security kernel updates Sasha Levin <sasha.levin@oracle.com> - 2016-04-21 16:00 +0200
            Re: stable-security kernel updates Jiri Slaby <jslaby@suse.cz> - 2016-04-21 17:00 +0200
              Re: stable-security kernel updates Sasha Levin <sasha.levin@oracle.com> - 2016-04-21 18:00 +0200
              Re: stable-security kernel updates Sasha Levin <sasha.levin@oracle.com> - 2016-04-21 21:40 +0200
        Re: stable-security kernel updates Bjørn Mork <bjorn@mork.no> - 2016-04-21 14:30 +0200
    Re: stable-security kernel updates Willy Tarreau <w@1wt.eu> - 2016-04-21 15:00 +0200
      Re: stable-security kernel updates Sasha Levin <sasha.levin@oracle.com> - 2016-04-21 16:20 +0200

Page 2 of 2 — ← Prev page 1 [2]

#1384311

[Multipart message — attachments visible in raw view] — view raw

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

[toc] | [prev] | [next] | [standalone]

#1384392

[Multipart message — attachments visible in raw view] — view raw

[Sorry I'm cutting out lots of stuff here, I just want to understand the point
below first]

On 04/21/2016 10:54 AM, Jiri Slaby wrote:
> 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.

So how exactly do commits go into your stable tree?

When I'm doing my stable work, I go through a range of mainline commits, see which
ones are stable material and follow the stable rules, and cherry pick them to my tree.

So at least in my case, there is patch selection every time I work on a stable tree.

I may end up thinking a given commit is not stable material, and people may point out
that it is, so I may end up going back and cherry picking it later. Have it never
happened with any of your trees?


Thanks,
Sasha

[toc] | [prev] | [next] | [standalone]

#1384531

[Multipart message — attachments visible in raw view] — view raw

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 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.

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 risk, right?

From 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, where the
security status is questionable. As I've mentioned, I'd be happy to discuss
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 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.

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 there 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 dumb 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 correct 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 though 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 making 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 make it up
just so I'll have more stuff to maintain, I started it because users simply 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 production, 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 not the case,
can we work together or improving it? Or at least not be sending each other inflammatory
mails about missing or not missing commits?


Thanks,
Sasha

[toc] | [prev] | [next] | [standalone]

#1384144

Sasha Levin <sasha.levin@oracle.com> writes:
> On 04/21/2016 02:43 AM, Jiri Slaby wrote:
>
>> Input: powermate - fix oops with malicious USB descriptors
>
> This requires physical access to the machine.

You wish.

Say you have some internal USB connected device with replacable
firmware.  LTE modem, fingerprint reader, webcam - you name it. How do
you know that this cannot be abused to impersonate some other USB
device?  Yes, changing the firmware of those devices should of course
require admin privileges.  But is that always so?  Writing firmware to a
modem, for example, is typically done over a serial device similar to
the one used for normal modem operations. Privileges necessary to manage
the modem will also include changing the firmware. Physical access is
not necessary.

Do you trust the firmware protection of all your non-removable USB
devices?


Bjørn

[toc] | [prev] | [next] | [standalone]

#1384176

On Wed, Apr 20, 2016 at 03:50:34PM -0400, Sasha Levin wrote:
> Hi all,
> 
> Updates for stable-security kernels have been released:
> 
> 	- v3.12.58-security
> 	- v3.14.67-security
> 	- v3.18.31-security
> 	- v4.1.22-security
> 	- v4.4.8-security
> 	- v4.5.2-security

Sasha, regardless the rest of the discussion in this thread, I find
myself confused by the naming above. For me, 3.12.58-something means
"something" on top of 3.12.58. Many (most? all?) forks work like this,
but here it seems that instead it's 3.12 + your selection of fixes
from kernels up to 3.12.58. I guess it would be much less confusing to
call it something like 3.12.0-security58 or something like this (or
maybe simply 3.12.0.58). Some people might be tempted to upgrade from
3.12.40 to 3.12.58-security and will possibly discover some breakage
due to bugs that were fixed between 3.12 and 3.12.40 and which are not
fixed in 3.12.58-security.

Thanks,
willy

[toc] | [prev] | [next] | [standalone]

#1384279

On 04/21/2016 08:56 AM, Willy Tarreau wrote:
> On Wed, Apr 20, 2016 at 03:50:34PM -0400, Sasha Levin wrote:
>> Hi all,
>>
>> Updates for stable-security kernels have been released:
>>
>> 	- v3.12.58-security
>> 	- v3.14.67-security
>> 	- v3.18.31-security
>> 	- v4.1.22-security
>> 	- v4.4.8-security
>> 	- v4.5.2-security
> 
> Sasha, regardless the rest of the discussion in this thread, I find
> myself confused by the naming above. For me, 3.12.58-something means
> "something" on top of 3.12.58. Many (most? all?) forks work like this,
> but here it seems that instead it's 3.12 + your selection of fixes
> from kernels up to 3.12.58. I guess it would be much less confusing to
> call it something like 3.12.0-security58 or something like this (or
> maybe simply 3.12.0.58). Some people might be tempted to upgrade from
> 3.12.40 to 3.12.58-security and will possibly discover some breakage
> due to bugs that were fixed between 3.12 and 3.12.40 and which are not
> fixed in 3.12.58-security.

That makes sense. I'll change that.


Thanks,
Sasha

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | linux.kernel

csiph-web