On Mon, Mar 21, 2022 at 10:56:55AM +0000, Richard Purdie wrote: > On Mon, 2022-03-21 at 10:43 +0000, mikko.rap...@bmw.de wrote: > > On Mon, Mar 21, 2022 at 10:37:17AM +0000, Richard Purdie wrote: > > > On Mon, 2022-03-21 at 07:48 +0000, mikko.rap...@bmw.de wrote: > > > > Hi, > > > > > > > > Thanks for the interesting patch! > > > > > > > > On Sat, Mar 19, 2022 at 07:25:55PM +0000, Richard Purdie wrote: > > > > > This adds support for a random kernel CVE monitoring tool which can be > > > > > run as a specific task against a kernel: > > > > > > > > > > $ bitbake linux-yocto -c checkcves > > > > > [...] > > > > > Sstate summary: Wanted 3 Local 3 Mirrors 0 Missed 0 Current 135 (100% > > > > > match, 100% complete) > > > > > NOTE: Executing Tasks > > > > > WARNING: linux-yocto-5.15.26+gitAUTOINC+ea948a0983_5bd4bda819-r0 > > > > > do_checkcves: Should consider cherry-pick for > > > > > be80a1d3f9dbe5aee79a325964f7037fe2d92f30:CVE-2021-4204 (NOT FOR THIS > > > > > VERSION) > > > > > WARNING: linux-yocto-5.15.26+gitAUTOINC+ea948a0983_5bd4bda819-r0 > > > > > do_checkcves: Should consider cherry-pick for > > > > > 20b2aff4bc15bda809f994761d5719827d66c0b4:CVE-2022-0500 (NOT FOR THIS > > > > > VERSION) > > > > > WARNING: linux-yocto-5.15.26+gitAUTOINC+ea948a0983_5bd4bda819-r0 > > > > > do_checkcves: Should consider cherry-pick for > > > > > 55749769fe608fa3f4a075e42e89d237c8e37637:CVE-2021-4095 (NOT FOR THIS > > > > > VERSION) > > > > > WARNING: linux-yocto-5.15.26+gitAUTOINC+ea948a0983_5bd4bda819-r0 > > > > > do_checkcves: Should consider cherry-pick for > > > > > 4fbcc1a4cb20fe26ad0225679c536c80f1648221:CVE-2022-26490 (NOT FOR THIS > > > > > VERSION) > > > > > WARNING: linux-yocto-5.15.26+gitAUTOINC+ea948a0983_5bd4bda819-r0 > > > > > do_checkcves: Should consider cherry-pick for > > > > > dbbf2d1e4077bab0c65ece2765d3fc69cf7d610f:CVE-2019-15239 (NOT FOR THIS > > > > > VERSION) > > > > > WARNING: linux-yocto-5.15.26+gitAUTOINC+ea948a0983_5bd4bda819-r0 > > > > > do_checkcves: Should consider cherry-pick for > > > > > 89f3594d0de58e8a57d92d497dea9fee3d4b9cda:CVE-2022-24958 (NOT FOR THIS > > > > > VERSION) > > > > > WARNING: linux-yocto-5.15.26+gitAUTOINC+ea948a0983_5bd4bda819-r0 > > > > > do_checkcves: Should consider cherry-pick for > > > > > 1bfba2f4270c64c912756fc76621bbce959ddf2e:CVE-2020-25220 (NOT FOR THIS > > > > > VERSION) > > > > > NOTE: Tasks Summary: Attempted 627 tasks of which 626 didn't need to > > > > > be rerun and all succeeded. > > > > > > > > > > Posted as an RFC to see what people think of this. I make no claims > > > > > on how useful it is/isn't but wanted to show integration isn't > > > > > difficult > > > > > and provide some inspiration for ideas. > > > > > > > > > > Details on the tool in question: > > > > > https://github.com/madisongh/kernel-cve-tool > > > > > > > > > > I've ignored the NO-FIXES-AVILABLE and PATCHED-CVES files. > > > > > > > > > > Signed-off-by: Richard Purdie <richard.pur...@linuxfoundation.org> > > > > > --- > > > > > meta/classes/kernel.bbclass | 10 ++++++++++ > > > > > .../kernel-cve-tool/kernel-cve-tool_git.bb | 20 > > > > > +++++++++++++++++++ > > > > > 2 files changed, 30 insertions(+) > > > > > create mode 100644 > > > > > meta/recipes-kernel/kernel-cve-tool/kernel-cve-tool_git.bb > > > > > > > > > > diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass > > > > > index 4f304eb9c7a..a842747b9d9 100644 > > > > > --- a/meta/classes/kernel.bbclass > > > > > +++ b/meta/classes/kernel.bbclass > > > > > @@ -753,6 +753,16 @@ addtask sizecheck before do_install after > > > > > do_strip > > > > > > > > > > inherit kernel-artifact-names > > > > > > > > > > +do_checkcves () { > > > > > + cd ${S} > > > > > + kernel-cve-tool -P ${STAGING_DATADIR_NATIVE}/kernel-cvedb > > > > > + while read -r line; do > > > > > + bbwarn "Should consider cherry-pick for $line"; > > > > > > > > cherry-picking isn't recommended. Instead, stable releases should be > > > > merged > > > > fully into product trees to fix CVE and other critical bugs. > > > > > > > > cherry-picking will miss bugs which don't yet have CVEs or exploits. > > > > cherry-picking will also miss non-obvious patch dependencies. > > > > > > > > Kernel community including Android documentation strongly recommends > > > > stable tree merges. > > > > > > If you have a stable tree available! > > > > As a git remote you always will. If you get a BSP Linux kernel without > > git version history, well you and your vendors are doing it all wrong. > > > > It is always possible to merge stable tree releases into vendor trees. > > > > The amount of hacks in vendor trees can make this hard, e.g. merge > > conflicts, but > > it is still the best practice which will be better in the long term instead > > of > > cherry-picking only CVE fixes. > > My point was that those stable trees only have a certain lifetime though. What > do you do once you're past that?
Update to a maintained LTS version. This can be done. If anyone thinks SOC vendors provide Linux kernel source trees which are product quality, well they are wrong. The SoC specific changes may be product quality from the vendors point of view and ok for the customer functionality, but there are millions of code lines in the kernel which are maintained by the kernel.org community and from which issues and bugs are discovered all the time. All the SoC vendors which I've worked with, and this is really long list, do it wrong. They provide a Linux kernel tree and rarely if ever update it with kernel.org (or Android) stable tree LTS releases. Thus they are not safe to use in products. An SoC vendor tree which is missing years of fixes is common. They are also missing generic subsystem patches for stability issues which customers then see if they test hard enough. > I appreciate the correct answer is upgrade. I suspect that isn't always an > option and having some idea of the security issues in your tree is probably > better than no idea. It's ok to provide the data of CVEs affecting the current kernel. The data is really useful and can also tell that no update is actually needed when the product configuration isn't affected by any of the mentioned issues. An update still makes sense a few times per year, though, because a lot of stable kernel fixes will get the CVE status years after the patches were merged once someone figures out an attack vector and a working exploit. I just do not want to recommend fixing the issues by applying a few cherry-picked patches. That's not the way to go with the Linux kernel. -Mikko
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#163499): https://lists.openembedded.org/g/openembedded-core/message/163499 Mute This Topic: https://lists.openembedded.org/mt/89894789/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
