search

anthraxx / linux-hardened

Minimal supplement to upstream Kernel Self Protection Project changes. Features already provided by SELinux + Yama and archs other than multiarch arm64 / x86_64 aren't in scope. Only tags have stable history. Shared IRC channel with KSPP: irc.libera.chat #linux-hardening
Other
567 stars 56 forks source link

kbuild's segmentation fault #5

Open skunk73 opened 5 years ago

skunk73 commented 5 years ago

strace.log.gz trying to compile virtualbox 5.2.28 with a patched 4.19.36 vanilla kernel leads to a segmentation fault: skunk@mescalito ~/VirtualBox-5.2.28 $ kmk VBOX_BUILD_PUBLISHER=_Gentoo TOOL_GCC3_CC=x86_64-pc-linux-gnu-gcc TOOL_GCC3_CXX=x86_64-pc-linux-gnu-g++ TOOL_GCC3_AS=x86_64-pc-linux-gnu-gcc TOOL_GCC3_AR=x86_64-pc-linux-gnu-ar TOOL_GCC3_LD=x86_64-pc-linux-gnu-g++ TOOL_GCC3_LD_SYSMOD=x86_64-pc-linux-gnu-ld 'TOOL_GCC3_CFLAGS=-march=native -O2 -pipe' 'TOOL_GCC3_CXXFLAGS=-march=native -O2 -pipe' 'VBOX_GCC_OPT=-march=native -O2 -pipe' TOOL_YASM_AS=yasm KBUILD_VERBOSE=2 all build debug: VBOX_WITH_NO_GCC_WARNING_POLICY is enabled kBuild: Pass - Build Programs kBuild: Generating /home/skunk/VirtualBox-5.2.28/out/linux.amd64/release/obj/Runtime/errmsgdata.h from /home/skunk/VirtualBox-5.2.28/include/iprt/err.h /home/skunk/VirtualBox-5.2.28/include/VBox/err.h kmk_builtin_redirect -wo /home/skunk/VirtualBox-5.2.28/out/linux.amd64/release/obj/Runtime/errmsgdata.h -- /usr/bin/kmk_sed -f /home/skunk/VirtualBox-5.2.28/src/VBox/Runtime/common/err/errmsg.sed /home/skunk/VirtualBox-5.2.28/include/iprt/err.h /home/skunk/VirtualBox-5.2.28/include/VBox/err.h kmk: *** [/home/skunk/VirtualBox-5.2.28/src/VBox/Runtime/Makefile.kmk:3011: /home/skunk/VirtualBox-5.2.28/out/linux.amd64/release/obj/Runtime/errmsgdata.h] Segmentation fault The failing command: $(QUIET)$(REDIRECT) -wo $@ -- $(SED) -f $< $(filter %.h,$^) kmk: *** Deleting file '/home/skunk/VirtualBox-5.2.28/out/linux.amd64/release/obj/Runtime/errmsgdata.h'

anthraxx commented 5 years ago

You need to provide a more depth analysis of your problem, but I don't see how this is a hardened patchset issue itself.

skunk73 commented 5 years ago

You need to provide a more depth analysis of your problem, but I don't see how this is a hardened patchset issue itself.

Because I can reliably reproduce the segmentation fault with your hardened patches applied, a vanilla kernel doesn't have this issue... find here the steps to reproduce it. (4.19.56 + 4.19.56.a patchset on gentoo linux)

anthraxx commented 5 years ago

@skunk73 can you bisect the problematic patch?

skunk73 commented 5 years ago

@anthraxx Does a broken down by "feature" patch set exist? I would be able to check every single patch and tell you which is causing the segfault. If you ask me to "git bisect", sorry but I don't know a "good" version of this kernel to start with... Unfortunately I wasn't able to get a coredump either :(

anthraxx commented 5 years ago

You said vanilla isn't affected, if you git clone the repo and check out 4.19-lts you could bisect starting with latest v4.19 tag and all the following patches on top of it.

The hardened patches are always rebaed on top of latest vanilla commits, which should make it fairly easy to do

skunk73 commented 5 years ago

No, I've never cloned your repo... I'll start to do it over night... Oh, I've no previous experience with bisect and just basic with git, so I'll need to study it first... (A cheat note is welcome) :)

anthraxx commented 5 years ago

basically from the 4.19-lts branch:

git bisect start HEAD v4.19.78

this will start the binary search, then just compile everything and test your usecase using the new built version, afterwards either:

# commit works
git bisect good 

# commit is broken
git bisect bad

is should then show you the commit that made your use case start throwing segfaults. Please initially verify using

git checkout v4.19.78

that it is working as expected before starting the bisect

skunk73 commented 5 years ago

I will schedule this reboot ballet over the weekend, thank you for the hint ;)

skunk73 commented 5 years ago

git checkout v4.19.78

sorry but there's no such branch/tag and I've no idea how to checkout vanilla 4.19.78 from this repo...

anthraxx commented 5 years ago

You can either fetch the vanilla tags by adding upstream kernel as another remote or use commit 58fce20645303bee01d74144ec00e405be43b1ca for the current 4.19-lts branch

skunk73 commented 4 years ago

...and the offending commit is d7a9818 btw, even kmk from debian/ubuntu's kbuild package show the same behaviour, so the issue isn't due exotic compile flags and therefore easy reproducible...