On Thu, Jan 30, 2025 at 9:31 AM Steve Sakoman via lists.openembedded.org <[email protected]> wrote:
> As you may be aware, the support period for Linux kernel LTS releases > has changed to two years. This presents a challenge for our Yocto LTS > releases, which have 4 year support periods. > > In light of this, Richard sent an email to the Yocto architecture list > in January of 2024 outlining the project's plans for kernel support in > future LTS releases (copied below) > > TLDR: Around the midpoint of the Yocto Scarthgap LTS lifecycle we will > backport the then current LTS kernel version and make it the default > kernel version. The linux-libc-headers version would remain at the > released version. > > At a recent Yocto Project Technical Team Meeting there was some > discussion around the growing kernel CVE counts in the stable > branches: > > kirkstone: 552 > scarthgap: 225 > > I hope these aren't based on the fact that I haven't sent the -stable updates to the list yet. I do the older branches on a monthly cadence, but can increase it. I have all active upstream kernels on their latest -stable in linux-yocto already. > For comparison the master branch CVE count for the kernel is 18 > > The suggestion was made that we do this kernel version update sooner > rather than later, and also include the Kirkstone LTS branch in order > to deal with its large number of CVEs. The original plan was to only > do this version bump for Scarthgap, so this would be a change to the > plan of record. > I don't think we should be updating kirstone to a new kernel while the upstream kernel's are active. Both 5.15 and 5.10 are still active on kernel.org and I'm still updating them, or am I missing something ? That was the primary trigger around the updates: EOL on k.org If we are now questioning the -stable process on k.org that it can't keep up on these still active LTS kernels, that is a different question. If we are questioning it, I have other suggestions around the reference kernel versions. But in the end, as long as the kernel we jump to is actively maintained in our newer releases, there's not a lot of extra work so it is fine with me. I just want to understand why we'd move kirkstone as well. Cheers, Bruce > > Please consider the above and respond to this email with any thoughts > or concerns you may have about implementing this version bump in both > LTS branches in the coming weeks. > > Thanks! > > Steve > > > Full text of Richard's email: > > The project is aware that the kernel versions that ship in our next LTS > in April will likely not have support for the full lifetime of our LTS > (four years). We've been asked a few questions about this so we wanted > to write down what our plan is. > > Our intent is to support the versions we ship with for as long as is > practical. If they become end of life around the mid point of the LTS > as expected, our plan is to backport a current LTS kernel at that time > into the release and make it the default, leaving the older recipes > there for anyone who still needs to use them. It would be based on the > kernel in one of our future releases, as appropriate. > > The linux-libc-headers version would remain at the released version. > This is used to control the features in the toolchain/userspace and > there is no need to upgrade this to work with a newer kernel version. > Upgrading it would potentially change the toolchain and userspace > functionality and this is not desirable in the LTS. To be clear, this > does mean bleeding edge features in the newer kernel may not be > available but that is desirable in the context of the purpose of the > LTS. > > The only reason the headers version would change would be to address a > security issue in the toolchain or kernel/userspace interface. > > Since we don't know what the upstream kernel will do, or when exactly, > it is hard to make a definitive plan beyond this. > > We appreciate this isn't our usual policy of "no upgrades", however if > everyone knows this is the plan from the start, we believe that is > different and everyone can plan accordingly, hence wanting to make this > clear now. > > Since the project is planning to execute the full QA process against > this new version, it is putting a plan in place to switch from the > start and it plans not to test against any other version beyond that > point, it makes most sense to directly integrate the changes rather > than the mix in layer approach which is there for unplanned changes. > > To be clear, we may also update this plan if/as things develop in the > other dependent ecosystems such as kernel as we can't know what will > happen in these on the timescales involved. > > Cheers, > > Richard > (on behalf of the Yocto Project TSC, LTS and kernel maintainers) > > > > -- - Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end - "Use the force Harry" - Gandalf, Star Trek II
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#210448): https://lists.openembedded.org/g/openembedded-core/message/210448 Mute This Topic: https://lists.openembedded.org/mt/110897884/21656 Group Owner: [email protected] Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
