Hi Bruce Am Do., 30. Jan. 2025 um 15:48 Uhr schrieb Bruce Ashfield via lists.openembedded.org <[email protected]>:
> > > 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. > Given the increasing importance of timely security updates and the rising frequency of new CVEs, staying as close as possible to the latest upstream kernels from kernel.org is becoming more essential than it was a few years ago. Additionally, patchsets such as preempt-RT, which were conveniently offered by the linux-yocto kernel, are now mainline. This raises the question: Is a downstream linux-yocto kernel git repository still needed? From my naive user's perspective, it would be simpler and more transparent if the kernel were handled like any other recipe. Instead of a linux-yocto recipe referring to a downstream git repository, there should be a linux and/or a linux-stable recipe referring to the corresponding git repositories from kernel.org. Ideally also the workflows for updating the kernel and testing the kernel would be possible with the Yocto standard workflows like devtool update and running oe-selftest. Thank you and regards, Adrian > > >> 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 (#211054): https://lists.openembedded.org/g/openembedded-core/message/211054 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]] -=-=-=-=-=-=-=-=-=-=-=-
