On Thu, Jan 30, 2025 at 03:37:50PM +0000, Marko, Peter wrote: > 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.
This is not true. E.g. meta-qcom is using linux-yocto. And, I think, that's the only viable way. So-called vendor kernels usually lag behind linux-yocto wrt LTS version (and the non-LTS kernels are just pain). I think we should be encouraging vendors to switch to linux-yocto, not discouraging them. > 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) -- With best wishes Dmitry
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#210469): https://lists.openembedded.org/g/openembedded-core/message/210469 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]] -=-=-=-=-=-=-=-=-=-=-=-
