ksummit.lists.linux.dev archive mirror
 help / color / mirror / Atom feed
From: Eduardo Valentin <edubezval@gmail.com>
To: Greg KH <greg@kroah.com>
Cc: ksummit-discuss@lists.linuxfoundation.org
Subject: Re: [Ksummit-discuss] [MAINTAINERS SUMMIT] Handling of embargoed security issues
Date: Sun, 9 Sep 2018 21:12:24 -0700	[thread overview]
Message-ID: <20180910041222.GA2524@localhost.localdomain> (raw)
In-Reply-To: <20180909125554.GB16474@kroah.com>

On Sun, Sep 09, 2018 at 02:55:54PM +0200, Greg KH wrote:
> 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.


Another example of divergence is meltdown itself, which made in 4.14
(Latest LTS) pretty close to what went into mainline, but anything older
than 4.14 got the core of meltdown implementation, but not all the
optimization in the x86 entry code, which was horrible to backport
entirely.

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

For these horrendous cases, should the community simply not patch the 
oldest kernels? Patching only the latest LTS may be a very strong
reason for everyone on older to simply go ahead and upgrade their kernels.

> 
> thanks,
> 
> greg k-h

  parent reply	other threads:[~2018-09-10  4:12 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
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 [this message]
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=20180910041222.GA2524@localhost.localdomain \
    --to=edubezval@gmail.com \
    --cc=greg@kroah.com \
    --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