scap kernel module fails to build on Linux >= 6.13

[dkogan]

Describe the bug

scap fails to build. Here's a bug report showing the failure with falcosecurity-libs 0.18.1: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1093098

I just tried with 0.20.0, and I see the same failure

How to reproduce it

Build against a recent-enough kernel

Environment

Debian amd64.

Thanks.

[FedeDP]

Hi!
I think the build issues you are facing come from:

[configure-kmod] Including /var/lib/dkms/scap/0.18.1/build//configure/ACCESS_OK_2/Makefile.inc /var/lib/dkms/scap/0.18.1/build//configure/CLASS_CREATE_1/Makefile.inc /var/lib/dkms/scap/0.18.1/build//configure/DEVNODE_ARG1_CONST/Makefile.inc
[configure-kmod] Build output for HAS_ACCESS_OK_2:
[configure-kmod] make: Entering directory '/var/lib/dkms/scap/0.18.1/build/configure/ACCESS_OK_2' make -C /var/lib/dkms/scap/0.18.1/build M=/var/lib/dkms/scap/0.18.1/build/configure/ACCESS_OK_2 modules make[1]: Entering directory '/var/lib/dkms/scap/0.18.1/b
uild' make[1]: *** No rule to make target 'modules'.  Stop. make[1]: Leaving directory '/var/lib/dkms/scap/0.18.1/build' make: *** [Makefile:15: all] Error 2 make: Leaving directory '/var/lib/dkms/scap/0.18.1/build/configure/ACCESS_OK_2'
[configure-kmod] Build output for HAS_CLASS_CREATE_1:
[configure-kmod] make: Entering directory '/var/lib/dkms/scap/0.18.1/build/configure/CLASS_CREATE_1' make -C /var/lib/dkms/scap/0.18.1/build M=/var/lib/dkms/scap/0.18.1/build/configure/CLASS_CREATE_1 modules make[1]: Entering directory '/var/lib/dkms/scap/0.
18.1/build' make[1]: *** No rule to make target 'modules'.  Stop. make[1]: Leaving directory '/var/lib/dkms/scap/0.18.1/build' make: *** [Makefile:15: all] Error 2 make: Leaving directory '/var/lib/dkms/scap/0.18.1/build/configure/CLASS_CREATE_1'
[configure-kmod] Build output for HAS_DEVNODE_ARG1_CONST:
[configure-kmod] make: Entering directory '/var/lib/dkms/scap/0.18.1/build/configure/DEVNODE_ARG1_CONST' make -C /var/lib/dkms/scap/0.18.1/build M=/var/lib/dkms/scap/0.18.1/build/configure/DEVNODE_ARG1_CONST modules make[1]: Entering directory '/var/lib/dkms
/scap/0.18.1/build' make[1]: *** No rule to make target 'modules'.  Stop. make[1]: Leaving directory '/var/lib/dkms/scap/0.18.1/build' make: *** [Makefile:15: all] Error 2 make: Leaving directory '/var/lib/dkms/scap/0.18.1/build/configure/DEVNODE_ARG1_CONST'

No rule to make target 'modules'

Basically, the build/configure/* modules are small kernel modules that gets built as part of the kmod build process to check whether various changes are present or not (mostly in case of backports where we cannot rely upon kernel version macros); here they are: https://github.com/falcosecurity/libs/tree/master/driver/configure

In your case, all these modules fail to build thus the driver build proceeds as if all of these checks failed, not enabling the usage of correct APIs.

Am not sure about what's causing the No rule to make target 'modules' failure though.

[dkogan]

Hi. This is building with dkms. Worked ok for a long time, and I see it building OK with 6.12, but it fails with 6.13.

You are correct in that the configuration is the part that is failing: with 6.12 I see these compile flags being used: -DHAS_ACCESS_OK_2 -DHAS_CLASS_CREATE_1 -DHAS_DEVNODE_ARG1_CONST. But with 6.13 these flags do not end up being used.

[dkogan]

Hi. The bug is here:

libs/driver/Makefile.in

Line 32 in 51410de

KERNELDIR ?= $(CURDIR)

Prior to 6.13, this is evaluated in the kernel source directory, and the code works as intended. However, in 6.13 the kbuild logic changed, and this is evaluated in the scap/ driver directory instead. This incorrect value of KERNELDIR then cascades, and eventually causes this build problem. Can you set the KERNELDIR in some other way?

Thanks

[dkogan]

One "fix" is to replace $(CURDIR) above with $(OLDPWD). Works with both 6.12 and 6.13 in my tests. Might fail in other places. Found by reporting all the non-CONFIG variables in that spot:

$(foreach v,$(.VARIABLES),$(if $(filter CONFIG%,$v),,$(info $v='$($v)')))

[FedeDP]

Hi! Thanks, this is the commit that introduced the change, i think: torvalds/linux@13b2548
Will look for a solution asap, thanks for reporting!

[FedeDP]

/milestone next-driver

[FedeDP]

@dkogan would you mind testing using:

KERNELDIR=$(srctree)

?
Given the torvalds/linux@13b2548 commit message, that should be it; quoting relevant part:

The command for building external modules maintains backward
compatibility, but Makefiles that rely on working in the kernel
directory may break. In such cases, $(objtree) and $(srctree) should
be used to refer to the output and source directories of the kernel.

[FedeDP]

It won't work; can you try invoking dkms with:

--kernelsourcedir ${KERNELDIR}

where KERNELDIR is of course the target kernel build folder, ie: /lib/modules/$VERSION/build.

[dkogan]

Hi. Notes:

• My hacky "fix" of using $(OLDPWD) doesn't actually work
• Using $(srctree) doesn't work either. I see srctree=/usr/src/linux-headers-6.12.8-common while we want /usr/src/linux-headers-6.12.8-amd64. These are not the same thing, and I don't see links from anywhere in -common to the main directory
• invoking dkms with an extra option wouldn't be useful: 99% of the time you don't run dkms yourself: apt does this for you in a hook. So you can't pass it extra options.

[dkogan]

Also, Linus's commit says to use either $(srctree) or $(objtree). In my builds there is no $(objtree)

[dkogan]

ALSO, I'd like to clearly point out that I'm using Debian and its packaged kernel sources (in the linux-headers-... packages. This is a very normal thing to do, but the kernel devs probably don't use these for the most part; probably the mostly use the kernel sources from git directly. So their proposed ways to work around this may not work for the Debian packaging (they probably don't have a separate -common, and thus for them maybe $(srctree) IS a usable workaround.

[dkogan]

I just tried something else that apparently does not work:

diff --git a/driver/Makefile.in b/driver/Makefile.in
index 7b1fdc2..1a261ea 100644
--- a/driver/Makefile.in
+++ b/driver/Makefile.in
@@ -26,13 +26,22 @@ clean:
 
 install: all
 	$(MAKE) -C $(KERNELDIR) M=$(TOP) modules_install
 
 else
 
-KERNELDIR 	?= $(CURDIR)
+ifeq ($(KERNELDIR),)
+  TAIL := /include/config/auto.conf
+
+  # sort to uniqueify the list
+  KERNELDIR := $(sort $(patsubst %$(TAIL),%,$(filter %$(TAIL),$(MAKEFILE_LIST))))
+
+  $(if $(KERNELDIR),,$(error "Couln't find the KERNELDIR by looking for %$(TAIL) in MAKEFILE_LIST: no matches; MAKEFILE_LIST is '$(MAKEFILE_LIST)'"))
+  $(if $(word 2,$(KERNELDIR)),$(error "Couln't find the KERNELDIR by looking for %$(TAIL) in MAKEFILE_LIST: too many matches; MAKEFILE_LIST is '$(MAKEFILE_LIST)'"))
+endif
+
 #
 # Get the path of the module sources
 #
 FIRST_MAKEFILE := $(firstword $(MAKEFILE_LIST))
 FIRST_MAKEFILE_FILENAME := $(notdir $(FIRST_MAKEFILE))
 FIRST_MAKEFILE_DIRNAME := $(shell basename $(dir $(FIRST_MAKEFILE)))

It looks at MAKEFILE_LIST for any Makefiles whose name ends in /include/config/auto.conf. In 6.13 it uniquely pinned it down to the correct (not -common) directory. But in 6.12 the MAKEFILE_LIST doesn't have the correct directory in it at all

[FedeDP]

Did you try #2277 (comment) by chance? I 🙏 that can fix the issue, but am not 💯 sure!

EDIT: we use this very same method to make dkms build in local builder for driverkit: https://github.com/falcosecurity/driverkit/blob/6e5086a9b05baad23148654f78a0898c368f8021/pkg/driverbuilder/builder/templates/local.sh#L42
, that's why i hope it is the correct one (since it sets the correct kernelsourcedir)