Re: KPTI for 4.1 LTS

[Willy Tarreau <w@1wt.eu>]

On Fri, Jan 19, 2018 at 01:23:08PM +0100, Greg KH wrote:
> On Fri, Jan 19, 2018 at 10:36:29AM +0000, Francesco Del Degan wrote:
> > On Fri, 19 Jan 2018 09:58:38 +0100, Greg KH wrote:
> > 
> > > Really?  What are you going to do when this goes end-of-life in 3
> > > months?  Seems like you should already be planning for that, right?
> > 
> > In EOL, we will be just like others that want to provide extended 
> > (custom) support, we are on our own. But that's is another problem, I 
> > guess.
> 
> It's a worse problem.  Unless you duplicate the effort that the stable
> maintainers do, your machines are going to be insecure.  Remember, it
> takes _more_ work to maintain a kernel longer, than it did previously.
> So soon you are going to be doing more work than I am, have fun!  :)

Not only this, but not benefiting from public reviews is the main
problem. In every single review I emitted for old kernels, there were
several comments like "this must not be backported there", "this backport
is erroneous" or "you need to also add these patches or it will be worse".
And even with this I managed to sometimes break something that had to be
fixed thanks to a users' report. Doing this discretely in one's garage
will inevitably result in the buggiest kernel you can think of. It will
lose some stability and very likely keep certain vulnerabilities incorrectly
fixed (ie backport considered complete once the reproducer stops working).

> And again, why can you just not update to a newer kernel version?  Do
> you have a huge out-of-tree patchset you rely on?  If so, best of luck,
> you should be billing whom ever forces you to use that code as it is not
> going to be easy.

In fact for having dealt with upgrades in our products myself, we've had
some product regressions on certain kernel upgrades (which were not
critical since in major branches). These were not necessarily kernel bugs,
but sometimes you discover that an old script relies on a specific format
of something in /proc or you're used to pass an option to a module and
this option has disappeared, etc. It's never a big deal but it definitely
takes some time. However I consider that the current offering of LTS kernels
definitely allows to jump from LTS to LTS at each major upgrade, keeping the
amount of revalidation effort reasonably low.

Quite frankly, Francesco, cut it in half, upgrade to 4.4 right now. It'll
be there for a while, leaving you with enough time to properly validate
other ones. The amount of difference between 4.1 and 4.4 is ridiculously
low and you'll even hardly notice anything. Then you'll have more time to
validate 4.9/4.14.

> good luck!

Seconded :-)
Willy