Kernel versions and security / Debian backports

I know the question of using the stable vs testing branch on a distro level, is settled for Whonix but I feel there are compelling arguments to raise it for the kernel package specifically as the most critical part for system safety and also because it’s self contained. Also in light of the spectre debacle and what fixes are not backported to older LTS kernels supported in stable are worth a new look.

Here is what Greg Kroah has to say as far as kernel security and the recommended versions one should run.

The number of security fixes that get backported are not as great as with the latest LTS release, because the traditional model of the devices that use these older LTS kernels is a much more reduced user model. These kernels are not to be used in any type of “general computing” model where you have untrusted users or virtual machines, as the ability to do some of the recent Spectre-type fixes for older releases is greatly reduced, if present at all in some branches.

So, here’s a short list of different types of devices, and what I would recommend for their kernels:

Laptop / Desktop: Latest stable release
Server: Latest stable release or latest LTS release
Embedded device: Latest LTS release or older LTS release if the security model used is very strong and tight.

The kernels in sid/testing/backports are usually not in sync with the ones listed as LTS on but I think they provide a good compromise between recency and stability.
My recommendation based on what he said is to have Whonix install the latest cloud version in backports to have the latest fixes and a lesser number of security bugs.


Big difference in kernel versions.

Stretch has 4.9 something, while backports has 4.17.17 at present. Totally agree with all this, and we should make a firm recommendation in the wiki.

1 Like

Wondering if/how this could be done in Whonix by default. Any

  • Debian (preferred)
  • (or third party [] deb?)

repository we could download kernel and headers from and then upload to Whonix repository?

What about Qubes VM kernel? How good is that one? Could anyone please submit feature request against Qubes?

That would help to make this argument better vetted (as far as stability, practicality, maintainability)!


It seems Qubes is basing off of the same version as in backports (4.17 as of writing).


*Offloading maintenance works and benefitting from safety measures taken by security conscious devs.


*Packaged as rpm. Not possible to use without hacks like running it through alien or explicitly changin the build process to output debs.
*We lose out on reproducible builds when they come online upstream when Buster comes around.
*We run much more code [0] than we need in a virtual environment compared to using [1]. They must do this however for maximum hardware compatibility but this isn’t in our scope for virtualized Whonix builds which are better off using the barebones kernel configs to cut down on attack surface.

[0] qubes-linux-kernel/config-base at master · QubesOS/qubes-linux-kernel · GitHub
[1] Debian -- Details of package linux-image-cloud-amd64 in stretch-backports

Debian -- Details of package linux-image-cloud-amd64 in stretch-backports - can consider. Could maybe download from stretch-backports and add to Whonix stretch repository. Could you manually test please if it works?

Also need Debian -- Details of package linux-headers-cloud-amd64 in stretch-backports.

Does Debian -- Details of package linux-image-cloud-amd64 in stretch-backports break Debian -- Details of package virtualbox-guest-x11 in stretch-backports? Could you manually test please if it works?

(I didn’t mean to suggest for Non-Qubes-Whonix to use the very same kernel package (rpm) as Qubes. While I don’t want to preemptively exclude it, I didn’t consider to research that. I guess alien will never be good enough and could go horribly wrong for a package as important as the linux package. Horribly wrong: missing maintainer scripts, kernel post install scripts, other incompatibilities Fedora vs Debian, breaking boot)

Observations for backports cloud image:

VM startup much quicker. 90% of boot time avoided.


  • Mouse cursor needs to be released from guest hotkey combination.
  • Shared folders on KVM broken because the module is not compiled into the kernel.
  • While it automatically fetches the VBox guest additions package there is an error message during the install that indicates the DKMS build is broken “Error!Bad return status for module build on kernel” I attached the log for those interested but it seems to be code problem with that package rather than a build dependency failure. Can’t upload log because forum forbids it.

So close but no cigar. Next up is regular backports which we can lockdown module loading for instead, at some point to reduce attack surface.

1 Like

Bug reports worth it or out of scope of that package?

Would that be fixed on recompilation of… Oh well, there is no guest additions to recompile so no joy?

Debian -- Details of package linux-headers-cloud-amd64 in stretch-backports certainly required for this.

Do guest additions from backports work?

Can we pick modules by an opt-in basis?

Its possible to compile a standalone module against the header for use even after the fact AFAIK.

Nope. Those are the ones from backports that are fetched automatically with this kernel is seems.

According to lockdown’s README yes you can. It’s not a strong guarantee as not having the code in the first place as someone with root can disable it, but it’s better than nothing.

However it only takes effect after a reboot which would be detectable by a user. So if one restores after a session the window of compromise is non-existent.

Configure by editing /etc/default/lockdown to enable/disable features
and adjust settings.

1 Like

Everything works as expected with full stable-backports. No errors burped out about VBox Guest Additions (the latest in backports which is automatically fetched).


Do you think it’s a maintainable solution to also grab lockdown from testing and upload it in Whonix repos?

I tested installing it and it needs no deps not present in stable.

The default setting locks in any detected loaded modules within 10 seconds of booting which should cover any built-in hardware.

1 Like

Debian has a cloud kernel initiative where they now have linux images optimized for performance on hypervisors and also contain the bare minimum modules needed to boot on major hypervisor platforms which is good for security. Though with the upcoming lockdown feature the extra modules can still be made off limits for attackers if not used.

This kernel version is available in buster and stretch backports which means we probably can’t use it for our purposes but good to consider for later.

1 Like

We could use testers here.


  • VirtualBox is are quite possibly ntot well tested with this kernel
    since it is as far as I know not much used in the cloud.
  • VirtualBox guest utilities might break or some other breakage.


  • This is unrelated to Qubes-Whonix since in Qubes-Whonix the kernel
    selection is not up to Whonix, but up to Qubes. (Same as Qubes Debian
1 Like

linux-image-cloud-amd64 does not boot in VirtualBox. Also not when removing hardening boot parameters by security-misc package. Also not in recovery mode. Just a black screen.

1 Like

Not sure if I’ve already reported this before but when I tried it, it was very minimalistic lacking even modules for shared folders to work. I think they are designed to work with KVM configurations so its almost certain VBox and Xen won’t be able to run it.

1 Like

Let’s consider Debian -- Details of package linux-image-amd64 in buster-backports.

One worry is that VirtualBox guest additions might break and be unfixeable for a while. While at the same time, downgrade to a kernel compatible with VirtualBox guest additions isn’t possible through in-place upgrades (apt dist-upgrade) for existing users.

1 Like

I assume the whole point of backporting though is to guarantee this type of bad breakage doesn’t happen? Including stuff from backports gets us some form of upstream support if it doesn’t work

Not sure. If I had to bet, I’d bet that breaking VirtualBox guest additions is a test case and blocker for kernel upgrades.

But even if the answer was “yes”, VirtualBox itself is currently not in backports, which is a mess. Therefore no such stability “guarantee”.
Only sid.
Debian -- Details of package virtualbox-guest-x11 in sid

1 Like

Can we add backports kernel only for non-VBox build flags?

1 Like
  • Build flag is doable in theory. But messy due to below…
  • Repository upgrades: not easy. Not possible without having separate apt repositories or some kind of packaging hack (Conflicts:?) which doesn’t install the backport kernel in VirtualBox.
1 Like

Also another thing I just thought of: enhanced security configs in security-misc may use features not available in the older stable kernel?

  • Is there a way we can test how things go with VBox before deploying this change?

  • What do users lose without functional guest additions installed? Maybe we can warn about installing them if everything else still works.

1 Like