kernel recompilation for better hardening

madaidan via Whonix Forum:

Will my lockdown patches ever be merged?

I can’t review them. And I haven’t found any other reviewer yet either.

If no upstream wants to take them (in that kernel version), then I can’t
review these patches either.

They’re almost identical to the upstream patches (excluding a different variable name and lockdown-kconfig.patch). The official lockdown patches won’t be coming to LTS anytime soon and there’s no other project I know of I can submit these to.

Similar or even 100% same as upstream patches. As said before backport
something, also the context on where these patches are plugged in have
to be understood which I don’t understand either.

They’re really important. Without them, root can easily escalate to
kernel mode, making “untrusted root” useless.

I’d rather re-consider a different kernel version in this case.

These kernel patches are imo also rushed ahead a lot. Solving
⚓ T960 hardened kernel Debian packaging and APT integration - hkapt isn’t trivial at all.


Should we compile more RNGs as built-in?

There are the following HWRNG options:


I think we should make CONFIG_HW_RANDOM_VIRTIO built-in for the VM kernel and the rest built-in for the host kernel.

There’s also another RNG module we might want to use, CONFIG_CRYPTO_ANSI_CPRNG, but I don’t know about that.

1 Like

No, because we chose to completely distrust hwrngs. I think we are better off stripping them out of the kernel.


We don’t. We only distrust them for initial entropy. Stripping them out entirely isn’t really a good idea.

Virtio RNG isn’t a real HWRNG anyway Features/Virtio RNG - Fedora Project Wiki


CLIP OS recently disabled CONFIG_STAGING.

kernel_config: Blacklist staging drivers · clipos/src_platform_config-linux-hardware@ec648fd · GitHub

From the docs:

Staging drivers are typically of lower quality and under heavy development. They are thus more likely to contain bugs, including security vulnerabilities, and should be avoided.

linux/Kconfig at master · torvalds/linux · GitHub

This option allows you to select a number of drivers that are not of the “normal” Linux kernel quality level. These drivers are placed here in order to get a wider audience to make use of them. Please note that these drivers are under heavy development, may or may not work, and may contain userspace interfaces that most likely will be changed in the near future.


1 Like

Kernel 5.5 will have an option to disable the iopl() and ioperm() syscalls.


Looks like a good candidate to disable. sys_rawio is one of those capabilities that I do not even like when it has to be there. As an example, when building app profiles with Apparmor, I always see if it can run with that one denied. I know it’s just one out of very many caps that could be potentially dangerous, but every bit helps.


It’s safe to use any source of entropy but not trust it / not credit it.

Entropy, Randomness, /dev/random vs /dev/urandom, Entropy Sources, Entropy Gathering Daemons, RDRAND


Good idea.

(Not suggested but just in case anyone would think that: Please don’t set any of these options to n (no). A better fallback is m just in case.)

1 Like

asked: Questions on seeeding, value of similar utilities · Issue #16 · smuellerDD/jitterentropy-library · GitHub

1 Like

This is super helpful since other eyes review these things! Thanks a lot for such upstreaming efforts!

(To nitpick: not exactly upstreaming just yet but similar helpful in long run.)


CONFIG_DRM_VBOXVIDEO is a staging driver. Is this actually used in vbox guests?

3 posts were split to a new topic: VirtualBox Guest Additions

madaidan via Whonix Forum:

Compile HWRNGs as built-in by madaidan · Pull Request #44 · Kicksecure/hardened-kernel · GitHub


1 Like

madaidan via Whonix Forum:

Disable staging drivers by madaidan · Pull Request #45 · Kicksecure/hardened-kernel · GitHub

A bit time consuming to review. Requires upgrade to newer kernel,


And then do these changes break



Actually needs to be reverted. We would have to be sure if these sources of entropy would be trusted / credited.

I don’t see much advantage over built-in vs module anyhow? For something important as this, better just keep it as default as module?


Are these modules auto load? And when auto load, is this entropy source credited / trusted?

1 Like