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 kernel.org but I think they provide a good compromise between recency and stability.
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  than we need in a virtual environment compared to using . 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.
(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)
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.
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.
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.
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.