ksummit.lists.linux.dev archive mirror
 help / color / mirror / Atom feed
From: Greg KH <greg@kroah.com>
To: Jiri Kosina <jikos@kernel.org>
Cc: ksummit-discuss@lists.linuxfoundation.org
Subject: Re: [Ksummit-discuss] [MAINTAINERS SUMMIT] Handling of embargoed security issues
Date: Sun, 9 Sep 2018 14:55:54 +0200	[thread overview]
Message-ID: <20180909125554.GB16474@kroah.com> (raw)
In-Reply-To: <nycvar.YFH.7.76.1809071526320.15880@cbobk.fhfr.pm>

On Fri, Sep 07, 2018 at 03:30:32PM +0200, Jiri Kosina wrote:
> On Thu, 6 Sep 2018, Eduardo Valentin wrote:
> 
> > Should we add maybe a point here to discuss which kernels are to be 
> > considered for patching in these cases? All the stable branches? Only 
> > mainline? Obviously, either extreme cases can hurt people. Patching 
> > older kernels requires insane amount of work and patching only mainline 
> > leaves distros on limbo.
> 
> That'd be mostly question for the stable guys I guess. I am not sure how 
> often did they in the past have to say "sorry, the backport is horribly 
> complex, so we are not backporting the fix and we're keeping the bug 
> unfixed".
> 
> Greg, is this something that actually has been happening for real in the 
> past? Or would that absolutely break the expectations that stable tree 
> consumers have?

Yes, this is something that is happening today.

If you look, L1TF is not fully backported to 4.4.y, for anyone running
4.4.y as a host operating system.  The backport was just too horrible
and no one wanted to do it and test it as all of the major hosting
services have moved on to 4.9.y or better.

There are other examples of this, spectre fixes for arm32 are not in any
stable tree older than 4.18.y.  Same for other arches and kernel
versions.

I tried to write up "what kernel version to use" on my blog a few weeks
back to answer this type of question.  Basically, only "trust" the
latest LTS stable kernel for security issues to be able to use it to run
untrusted users.  When you start getting older kernels involved, nasty
problems like what Meltdown and the like are having to implement, it
just does not work.

So only "stay" with on old LTS kernel if your hardware requires you to
(i.e. the horrid SoC nightmare).  And even then, be careful about things
(sandboxes, selinux, etc.) and go yell at your SoC vendor for forcing
you into this nightmare of a problem.  If they do not hear from
companies, they will not change.

thanks,

greg k-h

  reply	other threads:[~2018-09-09 12:55 UTC|newest]

Thread overview: 54+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-09-06 19:18 Jiri Kosina
2018-09-06 20:56 ` Linus Torvalds
2018-09-06 21:14   ` Jiri Kosina
2018-09-06 22:51     ` Eduardo Valentin
2018-09-07  9:17   ` Jani Nikula
2018-09-07 14:43   ` David Woodhouse
2018-09-06 22:55 ` Eduardo Valentin
2018-09-07  8:21   ` Geert Uytterhoeven
2018-09-10 23:26     ` Eduardo Valentin
2018-09-11  8:45       ` Greg KH
2018-09-11 17:10         ` Dave Hansen
2018-09-11 18:28           ` Greg KH
2018-09-11 18:44           ` Thomas Gleixner
2018-09-07 13:30   ` Jiri Kosina
2018-09-09 12:55     ` Greg KH [this message]
2018-09-09 19:48       ` Jiri Kosina
2018-09-10  4:04         ` Eduardo Valentin
2018-09-12  7:03           ` Greg KH
2018-09-10  4:12       ` Eduardo Valentin
2018-09-10 11:10       ` Mark Brown
2018-09-12  4:22   ` Balbir Singh
2018-09-08  4:21 ` Andy Lutomirski
2018-09-08  8:56   ` Thomas Gleixner
2018-09-08 11:21     ` Mauro Carvalho Chehab
2018-09-08 11:34       ` Greg KH
2018-09-08 14:20         ` Andy Lutomirski
2018-09-08 15:29           ` Greg KH
2018-09-08 15:00         ` James Bottomley
2018-09-08 15:32           ` Greg KH
2018-09-08 15:54             ` James Bottomley
2018-09-08 19:49               ` Linus Torvalds
2018-09-08 21:24                 ` James Bottomley
2018-09-08 22:33                   ` Andy Lutomirski
2018-09-09 12:18                     ` Mauro Carvalho Chehab
2018-09-10 22:59                 ` Dave Hansen
2018-09-11  8:48                   ` Greg KH
2018-09-09 12:51               ` Greg KH
2018-09-09 14:20                 ` Linus Torvalds
2018-09-09 14:38                   ` James Bottomley
2018-09-09 14:51                     ` Andy Lutomirski
2018-09-09 17:20                       ` Theodore Y. Ts'o
2018-09-09 17:48                         ` David Woodhouse
2018-09-09 18:17                         ` Andy Lutomirski
2018-09-09 18:56                           ` Theodore Y. Ts'o
2018-09-09 19:19                             ` Andy Lutomirski
2018-09-09 20:20                             ` Jiri Kosina
2018-09-09 21:36                               ` James Bottomley
2018-09-10  9:25                             ` Thomas Gleixner
2018-09-10 14:40                               ` James Bottomley
2018-09-11  8:20                               ` Jiri Kosina
2018-09-11  9:03                                 ` Thomas Gleixner
2018-09-09 19:41                   ` Jiri Kosina
2018-09-08 19:26           ` Jiri Kosina
2018-09-08 19:47             ` James Bottomley

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=20180909125554.GB16474@kroah.com \
    --to=greg@kroah.com \
    --cc=jikos@kernel.org \
    --cc=ksummit-discuss@lists.linuxfoundation.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