hello-world fails to build

[visar]

Trying to build hello-world as described here, but I'm getting this error:

   Compiling linux-kernel-module v0.1.0 (/home/vnz/work/playground/linux-kernel-module-rust)
error: failed to run custom build command for `linux-kernel-module v0.1.0 (/home/vnz/work/playground/linux-kernel-module-rust)`

Caused by:
  process didn't exit successfully: `/home/vnz/work/playground/linux-kernel-module-rust/hello-world/target/debug/build/linux-kernel-module-b8153acc5bce9d04/build-script-buil
d` (exit code: 1)
--- stdout
cargo:rerun-if-env-changed=KDIR
cargo:rerun-if-env-changed=CLANG
cargo:rerun-if-changed=kernel-cflags-finder/Makefile

--- stderr
kernel-cflags-finder did not succeed
stdout: -nostdinc -isystem /usr/lib/clang/8.0.1/include -I/usr/lib/modules/5.2.8-1-MANJARO/build/./arch/x86/include -I/usr/lib/modules/5.2.8-1-MANJARO/build/./arch/x86/inclu
de/generated -I/usr/lib/modules/5.2.8-1-MANJARO/build/./include -I/usr/lib/modules/5.2.8-1-MANJARO/build/./arch/x86/include/uapi -I/usr/lib/modules/5.2.8-1-MANJARO/build/./a
rch/x86/include/generated/uapi -I/usr/lib/modules/5.2.8-1-MANJARO/build/./include/uapi -I/usr/lib/modules/5.2.8-1-MANJARO/build/./include/generated/uapi -include /usr/lib/mo
dules/5.2.8-1-MANJARO/build/include/linux/kconfig.h -D__KERNEL__ -Wall -Wundef -Werror=strict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common -fshort-wchar -fno-P
IE -Werror=implicit-function-declaration -Werror=implicit-int -Wno-format-security -std=gnu89 -no-integrated-as -Werror=unknown-warning-option -mno-sse -mno-mmx -mno-sse2 -m
no-3dnow -mno-avx -m64 -mno-80387 -mstack-alignment=8 -mtune=generic -mno-red-zone -mcmodel=kernel -DCONFIG_X86_X32_ABI -DCONFIG_AS_CFI=1 -DCONFIG_AS_CFI_SIGNAL_FRAME=1 -DCO
NFIG_AS_CFI_SECTIONS=1 -DCONFIG_AS_SSSE3=1 -DCONFIG_AS_AVX=1 -DCONFIG_AS_AVX2=1 -DCONFIG_AS_AVX512=1 -DCONFIG_AS_SHA1_NI=1 -DCONFIG_AS_SHA256_NI=1 -Wno-sign-compare -fno-asy
nchronous-unwind-tables -mretpoline-external-thunk -fno-jump-tables -fno-delete-null-pointer-checks -Wno-address-of-packed-member -O2 -fplugin=./scripts/gcc-plugins/structle
ak_plugin.so -fplugin-arg-structleak_plugin-byref-all -DSTRUCTLEAK_PLUGIN -Wframe-larger-than=2048 -fstack-protector-strong -Wno-unused-but-set-variable -pg -Wdeclaration-af
ter-statement -Wvla -Wno-pointer-sign -Wno-unknown-warning-option -DMODULE

stderr: clang-8: error: unknown argument: '-fplugin-arg-structleak_plugin-byref-all'
make[2]: *** [scripts/Makefile.build:285: /home/vnz/work/playground/linux-kernel-module-rust/kernel-cflags-finder/dummy.o] Error 1
make[1]: *** [Makefile:1597: _module_/home/vnz/work/playground/linux-kernel-module-rust/kernel-cflags-finder] Error 2
make: *** [Makefile:33: all] Error 2

I'm on Manjaro Linux 18.0.4, with Linux kernel 5.2.8-1.

[geofft]

Ugh, that looks like your kernel is built with the structleak GCC plugin, and being a GCC plugin it won't run on clang, which we use to parse the header files.

I think that structleak doesn't change the ABI, so you ought to be able to filter out the argument and have things work. Can you try modifying build.rs (or kernel-cflags-finder itself) to skip it? It might be as simple as adding an if !arg.contains("structleak") {...} around the call to builder.clang_arg, or something.

[p2mate]

Same happens on arch linux (kernel version 5.3.5-arch1-1-ARCH) with clang 9. Problem is that the kernel-cflags-finder uses clang to compile a dummy module but clang doesn't support this feature. I worked around it by modifying /lib/modules/5.3.5-arch1-1-ARCH/build/scripts/Makefile.gcc-plugins to not add GCC_PLUGINS_CFLAGS to KBUILD_CFLAGS.

[DianaNites]

Changing the flag finder make call to $(MAKE) GCC_PLUGINS_CFLAGS= -C $(KDIR) M=$(CURDIR) CC=$(CLANG) also stops the flags, in my experience.

Added benefit, no need to modify kernel sources.

[mjaric]

Hi, how to filter -Wno-unused-but-set-variable flag?

CLANG: 9, 10
OS: Manjaro Linix 20.0.3
kernel: 5.6.19-2

[alex]

@mjaric that issue should be fixed by #227

[geofft]

For plugins in general, I think the challenge is that randstruct does change the ABI and we need to break the build if you have it (or at least tell you to find a version of clang that supports randstruct), so we can't just set GCC_PLUGINS_CFLAGS to empty for everyone. I suspect none of the other plugins change the ABI, but we should check that carefully, and have a positive list of known safe plugins.

I'm going to try to tackle this after some build system work - I'm trying to revive the change from #185 to move the logic of kernel-cflags-finder into build.rs, and I have that almost working. Once that's done, we can write this filtering logic in Rust instead of in make.

[geofft]

randstruct is the only one that adds itself to modversions.

But, I looked through them all to confirm:

• cyc_complexity: no ABI impact (only produces diagnostics)
• sancov: no ABI impact. It sounds like fsanitize-coverage=trace-pc (which clang supports) is equivalent, I wonder if they're compatible. (But even if not, this is at most "kcov will misbehave," not "the module will misbehave")
• latent entropy: no ABI impact (only affects things with a certain attribute)
• randstruct: changes struct layout, seed included in the kernel headers in scripts/gcc-plugins/randomize_layout_seed.h
• arm_ssp_per_task: seems to set task-specific stack smashing protection canaries because of some ARM-specific complication (torvalds/linux@189af46)? It overrides code that tries to load __stack_chk_guard, but I think there is no ABI impact other than that, and I think nobody has any legitimate business accessing that value beyond the core kernel init/entry/exit functions anyway. That variable isn't exported to modules if this plugin is enabled, so at least for the purposes of modules, I think it's fine. (I am confused why it's exported at all!)
• stackleak: strictly speaking, no ABI impact, but this plugin instruments all calls to find the maximum stack depth (so it can wipe the stack on syscall return). If the deepest function is a Rust function, it may not get completely wiped. Maybe we should print a warning, but compiled code will be compatible.
• structleak: no ABI impact - this zero-initializes (or 0xAA-initializes) certain uninitialized data depending on what you set it to, but there's no ABI incompatibility from not doing so, the data's still considered uninitialized from the point of view of C.

[geofft]

Sigh. So I have a fix for the plugin issue, but it turns out you can't actually compile it after last night's refactoring to drive the build with CC=clang because clang as called by Kbuild to link the .ko gets thrown the -fplugin arguments. So I have a Rust .o that built fine because I filtered them out in build.rs, but I can't turn that into a kernel module. :( We'll need to figure out some Kbuild magic somehow.

Also, note that this is going to require LLVM/Clang 11 (currently release candidate) because Manjaro is on a new enough kernel that it's using asm inline, which Clang just got support for https://reviews.llvm.org/D75563 . It doesn't seem to be packaged in Arch/Manjaro, but I'm using the binaries built by LLVM and setting CLANG and LLVM_CONFIG_PATH and that seems to be enough.

[geofft]

For the sake of pushing my work-in-progress somewhere, 68ad09b does compile on Manjaro's 5.6 kernel, but there are some definite Makefile crimes in there :)