Added support for 5.15.* builds

[zenmonkeykstop]

A few maintenance fixes:

• Updated buster image to 20211220
• added support for grsec stable6 (5.15.*) patches, removing old patches and skipping stable5 (5.10)
• added Makefile target for 5.15.* kernel builds
• updated 5.15 config to disable KVM support and build the igc network driver (required by NUCs with Intel i255v ethernet).
• added a note in the readme about source tarballs...

[zenmonkeykstop]

...Also had no luck with bullseye and gcc 10, getting early errors like Cannot use CONFIG_GCC_PLUGINS: your gcc installation does not support plugins, perhaps the necessary headers are missing? on running any make *config commands. gcc-10-plugin-dev was added to package list with no effect.

[zenmonkeykstop]

gcc 10 on bullseye is failing due to the plugins check bombing out as follows:

./scripts/gcc-plugin.sh gcc; echo $?
Using built-in specs.
COLLECT_GCC=gcc
OFFLOAD_TARGET_NAMES=nvptx-none:amdgcn-amdhsa:hsa
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 10.2.1-6' --with-bugurl=file:///usr/share/doc/gcc-10/README.Bugs --enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++,m2 --prefix=/usr --with-gcc-major-version-only --program-suffix=-10 --program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --enable-bootstrap --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-vtable-verify --enable-plugin --enable-default-pie --with-system-zlib --enable-libphobos-checking=release --with-target-system-zlib=auto --enable-objc-gc=auto --enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-offload-targets=nvptx-none=/build/gcc-10-Km9U7s/gcc-10-10.2.1/debian/tmp-nvptx/usr,amdgcn-amdhsa=/build/gcc-10-Km9U7s/gcc-10-10.2.1/debian/tmp-gcn/usr,hsa --without-cuda-driver --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu --with-build-config=bootstrap-lto-lean --enable-link-mutex
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 10.2.1 20210110 (Debian 10.2.1-6) 
COLLECT_GCC_OPTIONS='-v' '-c' '-std=gnu++98' '-fsyntax-only' '-I' './scripts/gcc-plugins' '-I' '/usr/lib/gcc/x86_64-linux-gnu/10/plugin/include' '-mtune=generic' '-march=x86-64'
 /usr/lib/gcc/x86_64-linux-gnu/10/cc1plus -quiet -v -I ./scripts/gcc-plugins -I /usr/lib/gcc/x86_64-linux-gnu/10/plugin/include -imultiarch x86_64-linux-gnu -D_GNU_SOURCE - -quiet -dumpbase - -mtune=generic -march=x86-64 -auxbase - -std=gnu++98 -version -fsyntax-only -o /dev/null -fasynchronous-unwind-tables
GNU C++98 (Debian 10.2.1-6) version 10.2.1 20210110 (x86_64-linux-gnu)
    compiled by GNU C version 10.2.1 20210110, GMP version 6.2.1, MPFR version 4.1.0, MPC version 1.2.0, isl version isl-0.23-GMP

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
ignoring duplicate directory "/usr/include/x86_64-linux-gnu/c++/10"
ignoring nonexistent directory "/usr/local/include/x86_64-linux-gnu"
ignoring nonexistent directory "/usr/lib/gcc/x86_64-linux-gnu/10/include-fixed"
ignoring nonexistent directory "/usr/lib/gcc/x86_64-linux-gnu/10/../../../../x86_64-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
 ./scripts/gcc-plugins
 /usr/lib/gcc/x86_64-linux-gnu/10/plugin/include
 /usr/include/c++/10
 /usr/include/x86_64-linux-gnu/c++/10
 /usr/include/c++/10/backward
 /usr/lib/gcc/x86_64-linux-gnu/10/include
 /usr/local/include
 /usr/include/x86_64-linux-gnu
 /usr/include
End of search list.
GNU C++98 (Debian 10.2.1-6) version 10.2.1 20210110 (x86_64-linux-gnu)
    compiled by GNU C version 10.2.1 20210110, GMP version 6.2.1, MPFR version 4.1.0, MPC version 1.2.0, isl version isl-0.23-GMP

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 048fcaee3460a99eb0d68522358720e1
In file included from /usr/lib/gcc/x86_64-linux-gnu/10/plugin/include/tm.h:26,
                 from /usr/lib/gcc/x86_64-linux-gnu/10/plugin/include/backend.h:28,
                 from /usr/lib/gcc/x86_64-linux-gnu/10/plugin/include/gcc-plugin.h:30,
                 from ./scripts/gcc-plugins/gcc-common.h:12,
                 from <stdin>:1:
/usr/lib/gcc/x86_64-linux-gnu/10/plugin/include/config/i386/i386.h:2500:10: fatal error: common/config/i386/i386-cpuinfo.h: No such file or directory
 2500 | #include "common/config/i386/i386-cpuinfo.h"
      |          ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
compilation terminated.
1

(with a couple of script edits to see said errors)

This is a known bug in Debian apparently: eg: https://www.mail-archive.com/[email protected]/msg58616.html

[conorsch]

Have yet to try a build locally, but your detailed output and upstream bug report seem to isolate the blocker pretty well. Zooming out a bit, since the goal is to support newer chipsets freedomofpress/securedrop#6170, maybe 5.10 is indeed the right target for us. The grsecurity download page labels the 5.15 patches as "beta", as well. Will still review and aim to merge this PR, but for the purposes of 2022 hw support, 5.10 is an easier reach—even if it commits us to bumping again by EOY.

[zenmonkeykstop]

Build according to grsecurity docs works fine directly in a Debian 10 VM with gcc 8.3.0 (at least as far as make -jN), so it's probably an issue with the Docker env specifically - wiil poke around some more tmw.

[zenmonkeykstop]

Have yet to try a build locally, but your detailed output and upstream bug report seem to isolate the blocker pretty well. Zooming out a bit, since the goal is to support newer chipsets freedomofpress/securedrop#6170, maybe 5.10 is indeed the right target for us. The grsecurity download page labels the 5.15 patches as "beta", as well. Will still review and aim to merge this PR, but for the purposes of 2022 hw support, 5.10 is an easier reach—even if it commits us to bumping again by EOY.

Sadly I was seeing the same compilation errors with 5.10, so we'd still have to sort that out. The 5.15 (stable6) patch listed as stable (not sure what's going on there), and the 5.10 is EOL this quarter, so IMO 5.15 is still the way to go.

[zenmonkeykstop]

I think I may actually have created confusion with the Debian 11 tangent and the error dumps above, so to summarize:

• 5.15.15 fails to build in the Docker Debian 10 + gcc 8.3.0 env due to the first errors posted, but naive grsecurity build works in a Debian 10 VM, so the root cause is probably localised to the Docker environment setup
• 5.15.15 fails early in a Docker Debian 11 + gcc 10.2.1-6 env due to the gcc plugin issue (second error) - this also fails in a non-Dockerized Debian 11 env. The root cause here is the gcc plugin support issue mentioned above and would require patching or an upstream fix to resolve.

Probably the fastest path to resolution imo is more troubleshooting of the Debian 10 docker env, and it's worth sticking with 5.15.15 as the target kernel due to grsecurity's long-term support plans for it.

[conorsch]

The root cause here is the gcc plugin support issue mentioned above and would require patching or an upstream fix to resolve.

According to https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=980609, a fix is own its way. I tried with debian:unstable as the image and did not encounter the bullseye error about missing the i386 headers. But as you say, we can shelve that for now.

worth sticking with 5.15.15 as the target kernel due to grsecurity's long-term support plans for it.

Thanks for clarifying that it's grsecurity where the EOL concern lies. The dates on the grsec download page don't match those on the official kernel timeline; i'll move discussion of 5.10 vs 5.15 to the issue!

[zenmonkeykstop]

https://patchwork.kernel.org/project/linux-kbuild/patch/[email protected]/ seems relevant, and would indicate that this is a compiler issue, so am taking another swing at building in Bullseye (pulling in the unstable gcc-10 packages to get around the gcc-10-plugin-dev bug above).

[zenmonkeykstop]

The security patch also seems to explicitly disable said warnings (as the allocations would fail anyway) so I'm not sure why we're still seeing them...

[zenmonkeykstop]

Aha - looks the warnings are being disabled overall, but for KVM support they're upgraded in the config to -Werror, hence the fail.

[zenmonkeykstop]

5.15.16 grsec kernels built with the config on this branch are working for me, with networking available, on a NUC11i5PAH over a default Ubuntu 20.04 installation.

It should be possible to just install the header and image debs with no grub edits - the 5.4 grsec kernels needed a noefi argument but that doesn't seem to be the case here. Said arg should probably still be set in the securedrop-grsec postint however, in case instances need to be downgraded to 5.4. it doesn't have any side-effects for our use case (as we don't expect users to be futzing about with EFI).

[gonzalo-bulnes]

General question: what does the test plan look like for this?

[conorsch]

For the sake of this PR, my plan is to:

1. run through build locally and confirm errors documented above are resolved
2. verify that source tarballs for 5.15.16 have been stored internally, so we can honor source requests
3. request debs added to apt-test

and then we're good to go on some more hardware testing with NUC11s.

[conorsch]

WFM! I'm able to get a working build on 5.15. Visual inspection of the config changes look great—specifically disabling kvm seems to have resolved the build errors, as you described. I don't have any 11th-gen hardware on hand to test, but that can come next, after we've settled the build logic for the 5.15 series. I have a single request before merge:

Please run dos2unix on the new config file, and squash down to one commit, summarizing the changes. Trying to diff locally against e.g. the 5.4 config, the different line endings made the diff output useless. Rather than push up a fix-it commit and screw with the history, rebasing seems the most considerate of future maintainers.

[conorsch]

Looks great. Reviewed full config diff (from 5.4 to 5.15), and no concerns with the rather minor changes. As you noted, @zenmonkeykstop, we could stand to prune the config a bit more vigorously, but let's do that after we make the jump to 5.15.