kernel recompilation for better hardening

madaidan via Whonix Forum:


Which one? Link?


We could make our own kernel package or fork linux-hardened.

I would like to understand a few things first.

What’s the diff between Debian https://packages.debian.org/buster/linux-image-amd64 and linux-hardened in descriptive terms? I.e. a possible (good) answer would be for example: “different kernel version + different kernel compile config + no Debian packaging files + additional arch linux packaging files”.

Can we just take their different kernel compile config, then use the Debian kernel source package ( https://packages.debian.org/source/buster/linux-signed-amd64 [?]), mix it together, rename the kernel package, and build the kernel package (using make deb-pkg by Debian kernel source package)?

[not make deb-pkg by genmkfile]

Or forget about the Debian buster stablized kernel version and use whatever version linux-hardened is using.

What about trust? The diff looks unreviewable. https://github.com/anthraxx/linux-hardened :

This branch is 134332 commits ahead, 4404 commits behind AndroidHardeningArchive:4.14-lts.

If it is by trustworthy people, we wouldn’t review the changes, trust signed git commits (hopefully existing already), then just add the Debian packaging files on top? If that even works?

Maybe we should ask the Debian devs?

Yes, please go ahead asking that. Hard to find existing discussions and I wonder why there haven’t been any after grsecurity was gone.

1 Like

The github repo.


There’s a different compile config, no Debian packaging files, hardening patches etc. It isn’t just a hardened compile config but actual changes in the code. The kernel version is different but we can use the LTS branch to be more in line with the Debian versions.

We could, but then we’d lose a lot of the hardening patches and changes to the code.

It was originally created by Daniel Micay and is now maintained by one of the Arch Security Team so I’d say it’s pretty trustworthy.

It should work although there may be some problems with using a kernel designed for rolling release distros on a stable one. The LTS kernel should have the least problems though and the best security due to the reduced attack surface (more features are added in stable kernels).

1 Like

Sounds like a good way forward. Could you try please if you get the Debian package build to function?

1 Like

I don’t know a lot about how Debian’s packaging system works so I don’t know where to start.

1 Like

In theory, just copy over the /debian folder of Debian’s kernel package. Then run make deb-pkg and see where it breaks.

1 Like

I cloned the linux-hardened git repo, copied the /debian folder from the linux-sources package and ran make deb-pkg. I got this error.

user@host:~/linux-hardened$ make deb-pkg
*** Configuration file ".config" not found!
*** Please run some configurator (e.g. "make oldconfig" or
*** "make menuconfig" or "make xconfig").
Makefile:655: include/config/auto.conf.cmd: No such file or directory
make: *** [Makefile:664: .config] Error 1

So I installed some needed packages and ran make menuconfig. I saved and exited. But I’m not sure if this overwrote the linux-hardened config or not. I did get this message

using defaults found in /boot/config-4.19.0-5-amd64

which makes it seem as if it was overwritten.

I then ran make deb-pkg again. I got this error a while after starting

make[4]: *** No rule to make target 'debian/certs/debian-uefi-certs.pem', needed by 'certs/x509_certificate_list'.  Stop.
make[3]: *** [Makefile:1072: certs] Error 2
make[2]: *** [debian/rules:6: build] Error 2
dpkg-buildpackage: error: debian/rules build subprocess returned exit status 2
make[1]: *** [scripts/package/Makefile:75: deb-pkg] Error 2
make: *** [Makefile:1421: deb-pkg] Error 2

I don’t know how to fix this.

1 Like

Can you compile a default Debian linux kernel which was received through package sources? Could be a good exercise in preparation. This might point us to the right steps to do it and then we “just” replace the underlying linux source. In theory.





Then also next level of difficulty: compiling kernel from kernel.org instead of Debian source package.

Only last step can be compiling linux-hardened since highest level of difficulty.

1 Like

This is outdated. make-kpkg isn’t used anymore.

This is interesting. It says

Alternatively, you can use the configuration from a Debian-built kernel that you already have installed by copying the /boot/config-* file to .config and then running make oldconfig to only answer new questions.

If you do this, ensure that you modify the configuration to set:


otherwise the build may fail:

make[4]: *** No rule to make target ‘debian/certs/test-signing-certs.pem’, needed by ‘certs/x509_certificate_list’. Stop.
make[4]: *** Waiting for unfinished jobs…

The build seemed to have copied the configuration from the kernel I already have installed and I didn’t configure any more options so this seems like it’s the cause of the problem above.

1 Like

I’m compiling the kernel now. It’s taking a while but I’m definitely passed the part where I got that error the last time. That seems to have fixed it.

1 Like

The kernel finally compiled. I installed it and when I booted into it, I got a black screen. I tried to access the systemd journal to see what happened but for some reason the logs of past sessions aren’t stored.

Is there something Debian or Whonix does that clears logs?

1 Like

It’s a default by Debian.

Documented how to make journal persistent here:



1 Like

I found the problem. For some reason, the page_poison=1 boot parameter is stopping linux-hardened from booting.

It works fine when I use this boot parameter on my host with linux-hardened. I think it might be something to do with the kernel configuration.

I’m not sure exactly what configuration the debian packaging is looking for. If we can find where it’s meant to be, we can probably add this config there and try compiling it again.

1 Like

I figured out where Debian looks for the config files. It’s in the directory you compile the kernel in and it’s called .config. I didn’t see it before as files that start with dots are hidden by default.

I’ll try compiling the kernel again but with the correct config.

1 Like

Using the correct config is even worse. I get this error

mount: mounting /dev/sda1 on /root failed: No such device
Failed to mount /dev/sda1 as root file system.

Then I get dropped into the initramfs prompt.

I tried clearing all of our custom boot parameters but it didn’t work. I also tried manually specifying the init and root with init=/sbin/init root=/dev/sda1 as boot parameters but that didn’t work either.

The systemd logs are here (I removed the abundance of “Opening SocksPort” Tor logs) but I can’t find anything except systemd’s “live-config-getty-generator” and virtualbox-guest-utils failing somehow.

1 Like

No idea. Some guesses.

madaidan via Whonix Forum:

Using the correct config is even worse. I get this error

mount: mounting /dev/sda1 on /root failed: No such device
Failed to mount /dev/sda1 as root file system.

Different grub boot parameters?

The systemd logs are here (I removed the abundance of “Opening SocksPort” Tor logs) but I can’t find anything except systemd’s “live-config-getty-generator” and virtualbox-guest-utils failing somehow.

Possibility that this is actually the journal of a previous boot with
functional kernel?

Other ideas:

Download pre-compiled kernel from linux-hardened and see if that boots
compared to self-compiled one.

Test in another virtualizer first.

Test on the host first.

Figure out serial console login to Linux on functional kernel.

Then serial console login to Linux on broken kernel (to gather more output).

Ask linux-hardened. Perhaps they find the idea of us hosting a Debian
package a cool idea to get more users and support this use case.

1 Like

I’ve tried different boot parameters.

No, the linux-hardened kernel version was 5.2.5 and the functional Debian kernel version was 4.19. You can see the kernel version at the top of the logs.

Also, this problem isn’t because of using a newer kernel as I managed to boot into the 5.2.5 kernel before just by removing page_poison=1.

I don’t think linux-hardened provides pre-compiled kernels. On their releases page, I only see a kernel patch meant to be used in compilation of an ordinary kernel.

linux-hardened always worked fine in different virtualizers for me so I don’t think that’s the problem. Although I never tested it on Debian before.

It works fine on my host.

I’m not sure how that would help.

1 Like
1 Like

Debian RFP: linux-hardened - hardened Linux kernel

1 Like


IMO packaging is some downstream job. Here are only pure kernel sources which are distro agnostic. Anyway adding one more patch to debian kernels should be trivial to do (assuming you are familiar with debian kernels packaging already).

In theory git checkout linux-hardened 5.2.6.a as well as debian kernel-team/linux git checkout 5.2.6-1, copy over the Debian folder from Debian linux kernel to linux-hardened and compile.

Could you try that please?

1 Like

Ben Hutchings:

On Thu, 2019-08-15 at 12:00 +0000, Patrick Schleizer wrote:

Package: linux
Severity: wishlist
X-Debbugs-CC: whonix-devel@whonix.org

Dear maintainer,

Could you please consider review and merge of linux-hardened patches
(free, Libre alternative to grsecurity).


Alternatively perhaps as a separate package.

RFP: linux-hardened - hardened Linux kernel


Any large patch set that is not upstream would need to be applied as an
optional “featureset”. (The “lockdown” patch set has been an exception
to this because Secure Boot was an obstacle to installing Debian and we
needed to support in the default kernel.) The requirements for a
featureset are roughly:

  • Its developers should be actively working to get those patches
  • There must be at least someone within the kernel team who takes
    responsibility for maintaining it.
  • It should have regular verifiable releases. (Also, if it isn’t
    updated for a new upstream version, we won’t wait for it but will
    disable building it temporarily.)

I would much prefer to see hardening changes that we can apply by
default, protecting the majority of Debian systems. We do apply some
small patches so that we can enable building high-risk features but
have them disabled at run-time by default. Even though these aren’t
upstream, they rarely require work to apply to new upstream versions.
I would certainly be open to changes of this sort.


1 Like
[Imprint] [Privacy Policy] [Cookie Policy] [Terms of Use] [E-Sign Consent] [DMCA] [Investors] [Priority Support] [Professional Support]