Grsec Kernel for Debian 8 Template VM now available

Coldhakca now has the Debian 8 Template VM booting with Grsec (coldkernel) and has successfully made AppVMs with it!!

Yes! Christmas has come early! :sunglasses: See screenshots here:

Should a tester template become available soon, sign me up! They have dom0, Fedora, and Whonix-WS and Whonix-GW on their ‘to do’ list next!

If Patrick or one of the more adventurous types wants to try it, the 4.8.9 and 4.8.10 kernels can be found here:

Apparently you have to run ‘make’ with the source file and patch, but I’m not up with building custom kernels.

Patrick, entr0py, any tips? This could finally solve the Grsec wishlist that many a forum poster has wanted for Whonix and Qubes.

Sorry if posted in the wrong forum, not sure where it belongs.

1 Like

Good day,

Moved this to General Tor and Anonymity Talk, as it doesn’t really fit in Support.

Have a nice day,


Sorry, don’t know much about this. Here is the qubes ML discussion:!msg/qubes-users/UwmSg_hniN0/Nd_IgdCYCQAJ

and a quote from

One thing we would not be able to take immediate advantage of in Qubes OS would
be the Subgraph-maintained grsec kernels. Even if we could package them properly
for use for the Qubes VMs (which should be easy), I'm not sure if the PV-nature
of our VMs would allow to get most benefit of things such as SMAP and SMEP,
potentially other protections...? But then again, Subgraph heavily use of
seccomp should provide significant hardening against the app->kernel attacks,
and for other attacks, specifically those coming from devices and networking and
usb stacks, we do have VM-isolated VMs.


This is unrelated to subgraph.

coldhak / coldkernel is specifically working on Qubes support.

you can say that I can do, if you have entered these commands?

I don’t say that. That’s just resources for getting more information and hints for experimenters.

1 Like

For future reference, it is worth noting that once Grsec templates are available in Qubes-Whonix within the next 6 months, the hardened Tor browser series is not going to play well with them.

Users will be required to run the default (stable) Tor browser instead.

The internet informs me that Grsec patches are incompatible with ASAN processes present in the hardened Tor browser series, due to PaX conflicts. Specifically:

PaX hard limits the maximum virtual memory size of a task in security/Kconfig:

…ASAN needs only 2 TB, but it needs them at a very specific address (to mirror the addresses used by the programm in the lower 2 TB of the address space), so at least 8 TB address space is needed to fit all the mappings at their expected addresses.

The effect is that ASAN will fail when it tries to allocate a large range of virtual memory for its shadow memory. This will result in errors when trying to start the hardened Tor browser, like this one seen in Gentoo:

==5223==Shadow memory range interleaves with an existing memory mapping. ASan cannot proceed correctly. ABORTING.

Addtional Pax flags will not work. The experts advise that it is still better to run the Grsec kernel, because ASAN is only really good for detecting (not preventing) memory corruption, whereas Grsec is designed to prevent exploitation.

A good technical guide - way, way above my paygrade - explaining the conflicts between Grsec and various memory clang sanitizers can be found here:

1 Like

The instructions for building the GrSec kernel for Qubes Debian 8 TemplateVM is now on-line. Whonix templates will come later.


Note: extremely alpha! It would make sense to try this with a cloned Debian TemplateVM, just in case you break things. The kernel has been bumped to 4.8.13, which is the latest version available at the time of writing.

I haven’t tried it, but I’m sure @Patrick won’t be able to resist! Note the building of the kernel can take hours and you need to increase your template size to at least 10GB.

Edit: See updated and clear working instructions below.

1 Like

We are currently working on supporting both Debian and Fedora TemplateVMs, however the below instructions assume a Debian 8 TemplateVM.

It is suggested that you create a dedicated Debian TemplateVM for experimenting with coldkernel. This support is very experimental, and may result in broken Templates.

Configuring Debian TemplateVM

First, change your max storage size to be 10GB (you can likely get away with anything over 4GB, however running out of disk space at the end of a build can be frustrating).

Fix sources.list

Open /etc/apt/sources.list and uncomment the lines starting with deb-src. It should look something like this:

deb Index of /debian jessie main contrib non-free
deb-src Index of /debian jessie main contrib non-free

deb jessie/updates main contrib non-free
deb-src jessie/updates main contrib non-free

Installing dependencies

Run in dom0:

sudo qubes-dom0-update grub2-xen

Run in your Debian TemplateVM:

sudo apt install qubes-kernel-vm-support grub2-common
sudo apt install paxctl bc wget gnupg fakeroot build-essential devscripts libfile-fcntllock-perl git gcc-4.9-plugin-dev
sudo apt-get build-dep linux

Building coldkernel

Cloning and verification

Once dependencies are installed, clone and verify the coldkernel build scripts on your TemplateVM:

wget “” -O coldhak.asc
gpg --import coldhak.asc
git clone GitHub - coldhakca/coldkernel: Hardened kernel generation - Deprecated
cd coldkernel
git verify-tag coldkernel-0.9a-4.8.13
git checkout tags/coldkernel-0.9a-4.8.13


Next, begin the coldkernel build. This step may take multiple hours depending on your hardware.

make qubes-guest

Installing coldkernel

Run in your Debian TemplateVM post-build:

gpg --homedir=.gnupg --verify paxctld_1.2.1-1_amd64.{deb.sig,deb}
sudo dpkg -i paxctld_1.2.1-1_amd64.deb
sudo make install-deb
sudo cp paxctld.conf /etc/paxctld.conf
sudo paxctld -d
sudo systemctl enable paxctld
sudo mkdir /boot/grub
sudo update-grub2
sudo shutdown -h now

Post-install TemplateVM configuration

Once the TemplateVM has been shutdown, you can change the kernel in the Qubes VM manager to pvgrub and start the VM.

1 Like

Grsec Whonix templates should be available within days for Qubes-Whonix. :slight_smile:

This message is a few days old from Coldhak team (my emphasis):


Please see Pull requests · coldhakca/coldkernel · GitHub
for the next steps along, with their planned release versions. We are currently planning to shift 0.9b within the next week.

0.9a (the current release) was not released with Fedora support, and this was pulled from the README before the release was cut. The 0.9b release will be focused on Whonix as well as Fedora, however Whonix is currently taking priority. The goal is to push out both Whonix and Fedora support with 0.9b, however if Fedora support looks like it will take considerably longer, it will be bumped to 0.9c.

For providing binary packages, our goal is to offer grsec enabled binaries for Debian. Offering pre-built Fedora binaries is not currently in the roadmap, however it could potentially be added down the line.

There are some protections that come with compiling the kernel by hand, such as an actually random/functional GRKERNSEC_RANDSTRUCT1.

Tested and working instructions for the Debian-8 template are already in the wiki here:

1 Like

The wiki instructions will need to preempt questions that grsec newbies (like me) will bring up in the future, so the same Qs aren’t answered over and over:

A new grsecurity patch has been released. How do I build with the new patch in my coldkernel TemplateVM?

This is not clear to me and Coldhak just says: run “make” (presumably make qubes-guest) with the new patch. That’s not gonna cut it for usability of the masses.

I want to run my grsec AppVMs as usbVM, netVM, firewallVM and/or the proxyVM, but they won’t connect or allow USB connections. What do I do?

It seems that config changes must be made to the coldkernel, so that more drivers are added to the kernel’s .config file BEFORE the step of running “make qubes-guest” (untested):


I’d be interested if anybody else has tried and been successful with this for networking and USB. If so, it should be recommended for experimenters.

I want to install the new grsec kernel version X.X.XX in my cold-kernel template, how do I do this?

There needs to be some general advice around how often the kernel should be updated. Qubes doesn’t update their base kernel for months at a time, but new grsec kernels seem to come out about every two weeks. It would be exhausting to build every time there is a new release.

Further, users will need to know which exact steps they are following to do this:

  • clone steps again?
  • just cd coldkernel, git-verify and git-checkout commands followed by running make-qubes-guest and installation steps?
  • deleting old configs, files and kernels first?



That’s not gonna cut it for
usability of the masses.

Certainly true.

The only thing that will work out is the grsecruty kernel downloadable
and all automagically from

Final tests for Whonix grsec templates (in Qubes) are underway! Fedora grsec templates are coming first though. (dom0 is a maybe).

But best of all… drum roll… binaries are planned in the future, meaning we won’t have to stuff around with building it manually :joy:

Hi everyone,

It has been some time since we posted on this list, so here is a brief

  1. We have recently pushed 0.9a-4.9.20
  1. An issue with switching from 4.8.x to 4.9.x was identified and fixed
    upstream (
  1. The blog post for Fedora support is currently being written
  1. Final tests for Whonix support are underway
  1. 0.9b will be released soon, with support for Fedora and 0.9c will
    follow soon after with full Whonix support (and a blog post, again.)
  1. Once 0.9c is out, we will direct our efforts towards providing
    binaries for Qubes users (and potentially our other supported platforms)
  1. After all above steps are complete, we will evaluate what the next
    steps should be. This may include attempting to provide a kernel for Dom0.

If anyone has questions / comments, please feel free to contact me directly.


Colin Childs
Twitter: @coldhakca

Advanced users note: you can try it now →

Thanks for all the hard work! WillyPillow just pointed out to me today on the qubes-devel mail list that installing busybox and updating initramfs in Whonix is all you need to do to get it to boot with coldkernel, and I just discovered myself a few minutes ago that for whonixcheck to work, you need to add ‘user’ to group 9001 (and for tor-browser to work properly, you need to disable memory protection using paxctl just like you do for regular Firefox). I haven’t gotten much further than that in my testing, though. In the meantime while we all wait for 0.9c, any other tips are appreciated!

1 Like

Thank you for the notification, would otherwise taken longer to reach me!

These are some great developments!

grsecurity Open Source is dead.

GitHub - coldhakca/coldkernel: Hardened kernel generation - Deprecated deprecated.

Sad news. Hopefully the hardening kernel project gets busy and doesn’t take 5 - 10 years to rip off Spengler’s ideas this time.