Re: [OE-core] [RFC PATCH] kernel: Add kernel-cve-tool support to help monitor kernel CVEs

[Richard Purdie <richard.purdie@linuxfoundation.org>]

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