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. https://source.android.com/devices/architecture/kernel/releases#keeping-a-secure-system "When deploying a device that uses Linux, it is strongly recommended that all LTS kernel updates be taken by the manufacturer and pushed out to their users after proper testing shows the update works well" http://kroah.com/log/blog/2018/02/05/linux-kernel-release-model/ "When deploying a device that uses Linux, it is strongly recommended that all LTS kernel updates be taken by the manufacturer and pushed out to their users after proper testing shows the update works well. As was described above, it is not wise to try to pick and choose various patches from the LTS releases..." I think the cherry-pick status is not useful, but the list of CVEs and patches to various subsystems is useful to users. IMO the tool should ask for a point release merge from upstream instead. > + done < ${S}/cherry-picks.list > +} > +do_checkcves[depends] = "kernel-cve-tool-native:do_populate_sysroot" > +addtask checkcves after do_configure > + > kernel_do_deploy() { > deployDir="${DEPLOYDIR}" > if [ -n "${KERNEL_DEPLOYSUBDIR}" ]; then > diff --git a/meta/recipes-kernel/kernel-cve-tool/kernel-cve-tool_git.bb > b/meta/recipes-kernel/kernel-cve-tool/kernel-cve-tool_git.bb > new file mode 100644 > index 00000000000..d2402bae052 > --- /dev/null > +++ b/meta/recipes-kernel/kernel-cve-tool/kernel-cve-tool_git.bb > @@ -0,0 +1,20 @@ > +HOMEPAGE = "https://github.com/madisongh/kernel-cve-tool/"; > +SRC_URI = > "git://github.com/madisongh/kernel-cve-tool;protocol=https;branch=master;name=tool > \ > + > git://github.com/nluedtke/linux_kernel_cves.git;protocol=https;branch=master;destsuffix=cvedb;name=data" Could the 'data' be handled like the CVE database and updated regularly/automatically? Cheers, -Mikko > +LICENSE = "MIT" > +LIC_FILES_CHKSUM = "file://LICENSE;md5=850b17d75c13807fada69140cf7cacc5" > + > +SRCREV_FORMAT ?= "tool_data" > +SRCREV_tool = "eb177abea3745d8576a725646effcce25f34302e" > +SRCREV_data = "b51a576dfbbd4d343b33bed0aa1fc4e095911938" > + > +S = "${WORKDIR}/git" > + > +inherit setuptools_build_meta > + > +do_install:append () { > + install -d ${D}${datadir}/kernel-cvedb > + cp -r ${WORKDIR}/cvedb/* ${D}${datadir}/kernel-cvedb > +} > + > +BBCLASSEXTEND = "native" > -- > 2.32.0 > > > >
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#163494): https://lists.openembedded.org/g/openembedded-core/message/163494 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] -=-=-=-=-=-=-=-=-=-=-=-
