Kernel versions and security / Debian backports

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

Not sure. Probably just ignored.

Yes. Try out.
That’s why all changes go through developers → testers → stable-proposed-updates → stable repository.

The problem here is, we cannot predict the future. If backport kernels will break VirtualBox guest additions.

Major things coming to mind:

  • Fixed screen resolution (too big, too small, scrolling, not using full window space, black border).
  • No shared folders.
  • No copy/paste from inside/outside VM.
  • Trapping of keyboard/mice inside VM until VirtualBox host key is pressed.
  • Performance?

more details here perhaps:

1 Like

The lesser evil. A packaging hack is the path of least resistance IMO.

1 Like

Or if we are enabling backports, then simply omit setting this apt config in VBox builds to begin with while designating the stable kernel during the build process?

1 Like

Enabling backports is inappropriate for a distribution.
Enabling backports alone does nothing. Still required APT pinning, which again is inappropriate for a distribution.

  • If not using virtualizer specific kernel versions: Would have to download the package from Debian backports and upload to Whonix stable.
  • If using virtualizer specific kernel versions: Would require some packaging hack. Perhaps require to recompile the kernel.

I don’t like the idea of virtualizer specific kernel versions. That’s adding a lot complexity. Hard to develop / test since involving different tests on different virtualizers.

It would also only be effective for a platform that I don’t maintain, KVM.
(Qubes is not yet Qubes VM kernel by default.)

1 Like

Debian bug linux-image-amd64 vs linux-headers-amd64 Debian buster-backports version mismatch bpo.2 vs bpo.3 shows that just enabling backports repository might lead to issues. In this example, breaking all kernel modules due to kernel image vs kernel headers version mismatch from backports

1 Like

OK. That’s a good citation for the wiki on why we don’t enable backports.

1 Like

added here:
Dev/APT Pinning - Kicksecure

1 Like