KPTI for 4.1 LTS

KPTI for 4.1 LTS

[Francesco Del Degan]

Hi everyone, do you know if there's any plan to backport the KPTI patches 
on 4.1 LTS? 

Cheers,
Francesco

Re: KPTI for 4.1 LTS

[Greg KH]

On Thu, Jan 18, 2018 at 08:16:57AM +0000, Francesco Del Degan wrote:
> Hi everyone, do you know if there's any plan to backport the KPTI patches 
> on 4.1 LTS?

Ick, why would you be using a kernel that is about to be end-of-life
anyway?  Why can't you use 4.9 or even better, 4.14?

Anyway, there is no plans that I know of, sorry.

best of luck,

greg k-h

Re: KPTI for 4.1 LTS

[Francesco Del Degan]

On Thu, 18 Jan 2018 10:40:17 +0100, Greg KH wrote:

> Ick, why would you be using a kernel that is about to be end-of-life
> anyway?  Why can't you use 4.9 or even better, 4.14?

Since we mantain a custom distro, upgrading to a different major kernel 
version is not an option atm (QA, etc).

I was asking just because we saw that some distro based on 4.1 as well 
(Oracle linux, etc) have patched it on its own, so we wondered if 
something more upstream would have been available before starting our 
backporting efforts too.

Due to particular nature of vulnerability I was expected that at least 
this would be patched in all *current* LTS (the 3.2 that shares the same 
EOL date was patched like 10 days ago).

> Anyway, there is no plans that I know of, sorry.

no problem

Thanks,
francesco

Re: KPTI for 4.1 LTS

[Greg KH]

On Fri, Jan 19, 2018 at 08:11:58AM +0000, Francesco Del Degan wrote:
> On Thu, 18 Jan 2018 10:40:17 +0100, Greg KH wrote:
> 
> > Ick, why would you be using a kernel that is about to be end-of-life
> > anyway?  Why can't you use 4.9 or even better, 4.14?
> 
> Since we mantain a custom distro, upgrading to a different major kernel 
> version is not an option atm (QA, etc).

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?

Also, you should always be able to run a new kernel on an old distro
with no problems, we made that guarantee over a decade ago and have not
broken it that I know of.  If something breaks, let us know.

> I was asking just because we saw that some distro based on 4.1 as well 
> (Oracle linux, etc) have patched it on its own, so we wondered if 
> something more upstream would have been available before starting our 
> backporting efforts too.
> 
> Due to particular nature of vulnerability I was expected that at least 
> this would be patched in all *current* LTS (the 3.2 that shares the same 
> EOL date was patched like 10 days ago).

If you will note, different people maintain the different trees, and
they all have different amounts of time they can devote to this:
	https://www.kernel.org/category/releases.html
If you were to provide working patches for 4.1, I'm sure that would make
things go quicker :)

thanks,

greg k-h

Re: KPTI for 4.1 LTS

[Francesco Del Degan]

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.

> If you will note, different people maintain the different trees, and
> they all have different amounts of time they can devote to this:
> 	https://www.kernel.org/category/releases.html

I know, and my question was way more practical: Trying to avoid to start 
backporting work that would been trashed after few days because it was 
already planned or started from someone else (and not announced to ml).

> If you were to provide working patches for 4.1, I'm sure that would make
> things go quicker :)

Sure, I will try to do it next days :-)

Thanks a lot,
francesco

Re: KPTI for 4.1 LTS

[Greg KH]

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!  :)

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.

good luck!

greg k-h

Re: KPTI for 4.1 LTS

[Willy Tarreau]

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