Security updates of Linux kernel (was: Re: Year 2038 time set problem)

Security updates of Linux kernel (was: Re: Year 2038 time set problem)

[Piotr Figiel]

Hi,

2018-02-26 15:16 GMT+01:00 Greg KH <greg@kroah.com>:
> On Mon, Feb 26, 2018 at 02:15:53PM +0100, Piotr Figiel wrote:
>> 2018-02-24 16:50 GMT+01:00 Greg KH <greg@kroah.com>:
>> > Also note that the 4.1 kernel is very old and obsolete and insecure, and
>> > should NOT be used for any devices in the year 2038.
>> According to kernel.org website 4.1 has projected EOL in May 2018.
> Yes, 3 months from now.
>> Is the information about kernel releases on kernel.org irrelevant/
>> shouldn't be trusted? Or my understanding of longterm kernel trees is
>> incorrect?
> No, it is correct, but note that since 4.1.y is about to be end-of-life,
> it is receiving very few updates.  No new device should be considering
> to use it for their kernel version because it will not be supported very
> soon now.

Yes, that's clear. I'm just concerned a bit that you wrote that 4.1 is
already insecure (while it's stated on kernel.org that it's currently
supported). I just wonder where is the boundary as to one can expect
the kernel to still get the security updates.
Is there a consensus about a reliable source of information which
kernels get fixes for certain security issues? Or is sticking with the
most recent /stable/ kernel the only recommended approach?
Commit messages often didn't mention any CVE or didn't indicate
clearly a security problem so it's pretty hard to track it
(semi-manually or automatically or without going in depth into commit
details).

Thanks,
Best regards, Piotr.

Security updates of Linux kernel (was: Re: Year 2038 time set problem)

[Greg KH]

On Mon, Feb 26, 2018 at 04:24:34PM +0100, Piotr Figiel wrote:
> Hi,
> 
> 2018-02-26 15:16 GMT+01:00 Greg KH <greg@kroah.com>:
> > On Mon, Feb 26, 2018 at 02:15:53PM +0100, Piotr Figiel wrote:
> >> 2018-02-24 16:50 GMT+01:00 Greg KH <greg@kroah.com>:
> >> > Also note that the 4.1 kernel is very old and obsolete and insecure, and
> >> > should NOT be used for any devices in the year 2038.
> >> According to kernel.org website 4.1 has projected EOL in May 2018.
> > Yes, 3 months from now.
> >> Is the information about kernel releases on kernel.org irrelevant/
> >> shouldn't be trusted? Or my understanding of longterm kernel trees is
> >> incorrect?
> > No, it is correct, but note that since 4.1.y is about to be end-of-life,
> > it is receiving very few updates.  No new device should be considering
> > to use it for their kernel version because it will not be supported very
> > soon now.
> 
> Yes, that's clear. I'm just concerned a bit that you wrote that 4.1 is
> already insecure (while it's stated on kernel.org that it's currently
> supported). I just wonder where is the boundary as to one can expect
> the kernel to still get the security updates.

It all depends.  Right now, 4.1.y is vulnerable to the Spectre issue.
As is 4.4.y.  Will those kernels ever get those fixes, who knows, do you
want to do the backport work, or just update to a newer kernel?

And depending on your architecture, 4.4.y and 4.9.y is vunerable to
Meltdown as well.  And those kernels will not get fixed for known
reasons I've documented elsewhere.

There are other issues that are fixed in newer kernels that are not
backported further back due to various issues, so you should always use
a newer kernel release to be sure.

> Is there a consensus about a reliable source of information which
> kernels get fixes for certain security issues? Or is sticking with the
> most recent /stable/ kernel the only recommended approach?

This.

> Commit messages often didn't mention any CVE or didn't indicate
> clearly a security problem so it's pretty hard to track it
> (semi-manually or automatically or without going in depth into commit
> details).

CVEs mean nothing, you can't rely on them.  They are only good for if a
bug is reported to the CVE numbering people, that's it.  And even then,
can you properly track a CVE issue that takes 100s of patches to resolve
(like Meltdown and Spectre do?)  I sure can not...

For a full description on this whole thing, please see this post where I
describe how the kernel developers treat "security" bugs, and how to
ensure you are running a secure system:
	http://www.kroah.com/log/blog/2018/02/05/linux-kernel-release-model/

Hope this helps,

greg k-h

Security updates of Linux kernel

[Bjørn Mork]

Greg KH <greg@kroah.com> writes:

> For a full description on this whole thing, please see this post where I
> describe how the kernel developers treat "security" bugs, and how to
> ensure you are running a secure system:
> 	http://www.kroah.com/log/blog/2018/02/05/linux-kernel-release-model/

 "At the current kernel release rate, the number will change to 5.x
  sometime in 2018."

That's bold.  Could cost you some very exclusive whisky if I understand
the version numbering process correctly.


Bj?rn

Security updates of Linux kernel

[Greg KH]

On Mon, Feb 26, 2018 at 05:49:42PM +0100, Bj?rn Mork wrote:
> Greg KH <greg@kroah.com> writes:
> 
> > For a full description on this whole thing, please see this post where I
> > describe how the kernel developers treat "security" bugs, and how to
> > ensure you are running a secure system:
> > 	http://www.kroah.com/log/blog/2018/02/05/linux-kernel-release-model/
> 
>  "At the current kernel release rate, the number will change to 5.x
>   sometime in 2018."
> 
> That's bold.  Could cost you some very exclusive whisky if I understand
> the version numbering process correctly.

I would be glad to pay that price :)

Security updates of Linux kernel

[Konstantin Ryabitsev]

On February 26, 2018 12:08:37 PM EST, Greg KH <greg@kroah.com> wrote:
>>  "At the current kernel release rate, the number will change to 5.x
>>   sometime in 2018."
>> 
>> That's bold.  Could cost you some very exclusive whisky if I
>understand
>> the version numbering process correctly.
>
>I would be glad to pay that price :)

I vote that we do it after 4.19 is out, just to avoid all the inevitable stoner jokes. 

Best,
-K