| Message ID | 20220319192555.1118739-1-richard.purdie@linuxfoundation.org |
|---|---|
| State | New |
| Headers | show |
| Series | [RFC] kernel: Add kernel-cve-tool support to help monitor kernel CVEs | expand |
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.purdie@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 (#163476): https://lists.openembedded.org/g/openembedded-core/message/163476 > Mute This Topic: https://lists.openembedded.org/mt/89894789/3616751 > Group Owner: openembedded-core+owner@lists.openembedded.org > Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [mikko.rapeli@bmw.de] > -=-=-=-=-=-=-=-=-=-=-=- >
On Mon, 2022-03-21 at 07:48 +0000, Mikko.Rapeli@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.purdie@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! > 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. I think a lot depends on the scenario you're using this in. The different ouputs are useful in different scenarios... > > > + 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? Something like: SRCREV_data = "${AUTOREV}" should do that. In some ways I prefer this to the CVE database approach since you always have a deterministic outcome for a given revision. Cheers, Richard
On Mon, Mar 21, 2022 at 10:37:17AM +0000, Richard Purdie wrote: > On Mon, 2022-03-21 at 07:48 +0000, Mikko.Rapeli@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.purdie@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. > > 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. > > I think a lot depends on the scenario you're using this in. The different ouputs > are useful in different scenarios... I'm sorry but really, there isn't anything else which will work in the long run. If anyone proposes cherry-picking Linux kernel CVE patches, they are doing it wrong. > > > > > + 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? > > Something like: > > SRCREV_data = "${AUTOREV}" > > should do that. In some ways I prefer this to the CVE database approach since > you always have a deterministic outcome for a given revision. Yep, good to know. Cheers, -Mikko
On Mon, 2022-03-21 at 10:43 +0000, Mikko.Rapeli@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.Rapeli@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.purdie@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? 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. > > > > 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. > > > > I think a lot depends on the scenario you're using this in. The different ouputs > > are useful in different scenarios... > > I'm sorry but really, there isn't anything else which will work in the long run. > If anyone proposes cherry-picking Linux kernel CVE patches, they are doing it wrong. Perhaps the message should say "potential CVE commit missing?" and cherry-pick was a poor choice based upon the upstream tool. Th data I didn't show may also be much more useful depending on the scenario but as I mentioned, it really was a patch just showing what could be possible rather than saying it was the right thing. Cheers, Richard
On Mon, Mar 21, 2022 at 10:56:55AM +0000, Richard Purdie wrote: > On Mon, 2022-03-21 at 10:43 +0000, Mikko.Rapeli@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.Rapeli@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.purdie@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
On Sat, Mar 19, 2022 at 8:26 PM Richard Purdie <richard.purdie@linuxfoundation.org> 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.purdie@linuxfoundation.org> > Thanks for posting the patch. Apart from the discussion about cherry-pick vs updating, here are my two comments: 1. For all such tools I would really prefer machine-readable output format, so we can parse it, generate reports etc. 2. The tool itself works only if the kernel history is included in the vendor's tree, they say in the README: Note that the script assumes that your branch is derived from one of the existing stable kernel labels (e.g., 'v4.9') - in other words, it must contain commits from one of the linux-X.Y branches in the stable repository, and have other commits added it to it. It means that there are cases when it doesn't work - especially when the vendor cherry-picked commits or imported all the kernel as one commit. I find it useful as another source of information in addition to the NVD database. It would allow correlation of the two and possibly limit mismatches. However, I can already see that the last commit is 2 weeks ago, so data might be outdated. Regards, Marta
On Sat, Mar 19, 2022 at 8:26 PM Richard Purdie <richard.purdie@linuxfoundation.org> wrote: > > 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. I was not aware of this particular tool, but it uses data from https://github.com/nluedtke/linux_kernel_cves (which is also used for www.linuxkernelcves.com). I have been using this data source for several years. I find it particularly useful for analysing the LTS kernel branches, because the NVD database really does not capture [1] the efforts that go into back-porting the fixes. It takes quite a bit of effort to figure out which CVEs are addressed in which commit, and then to determine if the commit is applicable to LTS branches, and whether it has been applied. The ww.linuxkernelcves.com largely automates this problem, and I've spot-checked quite a few of its results, and found them to be correct. The project typically updates every week or so. So, I for one would welcome a way to include this in the yocto build, as I am currently doing this manually with post-processing. As the others replies have indicated, the phrasing of "consider cherry-pick" is probably not ideal. Ideally, the output would be formatted the same as the existing cve-check tool, although a simple list of applicable/unpatched CVEs would also suffice. I just got it working against my dunfell branch, so I will do a bit of experimentation... Regards, Ralph [1] This might change in the upcoming NVD JSON 5.0 format, which now allows using git hashes to describe the status of multiple branches. Though it remains to be seen if these new features will actually get used.
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"; + 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" +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"
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.purdie@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