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 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. 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)
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#210447): https://lists.openembedded.org/g/openembedded-core/message/210447 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]] -=-=-=-=-=-=-=-=-=-=-=-
