Re: version bump of minimal kernel version supported by systemd?

[Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx>]

On Wed, Mar 23, 2022 at 03:58:22PM +0000, Luca Boccassi wrote:
> On Wed, 2022-03-23 at 12:38 +0100, Greg KH wrote:
> > On Wed, Mar 23, 2022 at 11:28:29AM +0000, Luca Boccassi wrote:
> > > On Wed, 2022-03-23 at 11:59 +0100, Zbigniew Jędrzejewski-Szmek wrote:
> > > > On Wed, Mar 23, 2022 at 09:26:05AM +0100, Greg KH wrote:
> > > > > On Wed, Mar 23, 2022 at 09:17:36AM +0100, Zbigniew Jędrzejewski-Szmek wrote:
> > > > > > On Wed, Mar 23, 2022 at 08:07:48AM +0100, Greg KH wrote:
> > > > > > > On Tue, Mar 22, 2022 at 05:27:07PM +0100, Zbigniew Jędrzejewski-Szmek wrote:
> > > > > > > > Hi all,
> > > > > > > > 
> > > > > > > > we are considering dropping upstream support for kernel versions < 4.4.
> > > > > > > > Would this be a problem for anyone? (*).
> > > > > > > 
> > > > > > > Given that upstream (i.e. kernel.org) has dropped support for kernel
> > > > > > > 4.4, why not just move to not supporting kernels older than 4.9?
> > > > > > 
> > > > > > It seems Civil Infrastructure Platform (a project under the Linux
> > > > > > Foundation) still uses 4.4 [1].
> > > > > 
> > > > > Yes, but they are not going to be updating to a newer version of
> > > > > systemd, right?
> > > > > 
> > > > > And they are going to be "supporting" that for 20+ years.  If they want
> > > > > to do something crazy like this, make them handle supporting code that
> > > > > is older than 6+ years to start with.  That's not the community's issue,
> > > > > that's the companies that demand such crazy requirement's issue.
> > > > 
> > > > That's why I (we) asked the question on the list. If people are compling
> > > > systemd on such old systems, or even older, we want to know about it.
> > > > 
> > > > > > In the Debian world, Stretch which has EOL scheduled for June 2022 has 4.9,
> > > > > > and after that Buster has 4.19.
> > > > > 
> > > > > 4.9 is fine, and is supported by kernel.org until next year as seen
> > > > > here:
> > > > > 	https://kernel.org/category/releases.html
> > > > > 
> > > > > I wrote "4.9" above, not "4.19" :)
> > > > 
> > > > Yep. I'd vote for bumping to 4.9, unless some other voices pop up.
> > > > 
> > > > Zbyszek
> > > 
> > > Let's do 4.4 at most please - what's on kernel.org is not really that
> > > important, as real usage is downstream from there anyway.
> > 
> > And I will publically state that anyone still using 4.4.y today has an
> > insecure and unsupported system.  Please let's not encourage _ANYONE_ to
> > do this.
> > 
> > CIP is "special" in that they know what they are doing, and are using
> > 4.4.y in a very limited set of use cases and configurations.  And even
> > they are going to have big problems keeping that kernel alive and
> > secure.  I would never expect anyone else to be able to do it, and I
> > have doubts that they will either.
> > 
> > So any "real usage" of 4.4 after today, should not matter.  And if
> > someone complains, send them to me please.
> > 
> > thanks,
> > 
> > greg k-h
> 
> You can publically state that all day long, but you know perfectly well
> that's not how the world works.

I am trying to _change_ how the world works, because the way it
currently works for some companies/distros is totally broken and
insecure.

To just ignore it is to give up.

> In the grand scheme of things few
> production scenarios build their kernel from kernel.org, most will be
> getting it from a distro (best case) or a vendor (worst case), and they
> couldn't care less about what kernel.org tells them to do, they use
> what they get.

But if kernel.org tells them that what they are using is insecure, they
should push back on their distro and vendor to have them prove that this
is not true.  So far I have never seen a distro or vendor that uses
older kernels without an insecure kernel.  And I've audited hundreds of
them.

> I fully expect at some point to hear complaints from
> some poor soul stuck on 3.x because of $crappy_arm_vendor with no way
> to move on from there.

Those people are not using new versions of systemd, are they?  And if
they are, they need to get $crappy_arm_vendor to do the work for them as
they PAID for that support and work already.

thanks,

greg k-h