Hello Steve, Some thoughts from my side: Linux-yocto is a reference kernel for qemu machines. They are good for experiments but will not go to a real product. So are the linux-yocto qemu kernel CVEs interesting at all? I bet that users of yocto have their own kernels. From this perspective of course upgrade is fine as no one is using it, but is it needed at all? Isn't it better to keep the original one so users who don't upgrade have a good comparison base? Maybe it would be interesting to have two kernel version - original + newest so that components can be tested on both, but only if both would also be tested on autobuilder.
We have split kernel and non-kernel CVEs in our reports since the beginning. For a different reason (each SOC needed its own vendor kernel at that time), but it made the metrics focused on what we needed. Kernel and other components are other worlds and probably no developer will be fixing both. I'd suggest doing the same in oe-core - split the kernel CVEs to a separate tables. This will not fix the numbers, but maybe help most users to see status of what they are using without overflowing from unused component with astronomical numbers. Third topic is regarding NVD CVE metric reporting. Currently it's bogus - not showing majority of CVEs and showing some which are already backported but never updated in the DB. I remember that Marta was working on annotations from cvelistV5, but somehow that activity died. Maybe there should be a restart of this to make the reports reliable/trustworthy? I think that kernel maintainers are backporting all relevant CVE fixes to all affected LTS branches. That should mean that with every update, we should be getting back close to 0 CVEs and just need a reliable data. Maybe a final comment... When we open this topic for kernel, there are other components where there is lot of CVEs which realistically cannot be backported. Those are usually handled via https://git.yoctoproject.org/meta-lts-mixins/, shouldn't it be the same for kernel? TLDR: Since I'm not using linux-yocto, I have just suggestions to reporting, no strong opinion on its upgrade. Peter > -----Original Message----- > From: [email protected] <openembedded- > [email protected]> On Behalf Of Steve Sakoman via > lists.openembedded.org > Sent: Thursday, January 30, 2025 15:31 > To: Patches and discussions about the oe-core layer <openembedded- > [email protected]> > Subject: [OE-core] Request for discussion: Kernel version for LTS releases > > 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 (#210452): https://lists.openembedded.org/g/openembedded-core/message/210452 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]] -=-=-=-=-=-=-=-=-=-=-=-
