kernel recompilation for better hardening

^ Merged.

Not happy with the realtek cards being broken, though. But at least I’ll added these to the wiki so this becomes at least possible to figure out using “google”.

^ There is now a merge conflict.

^ Could you please document the devices similar to the ones already documented at hardened-kernel?

1 Like

EFI isn’t supported in VMs. Whonix VMs only support BIOS booting.

No point in enabling a large amount of code barely anyone will be using.

1 Like

Created a new PR.

@Patrick can you maintain the versioning from now on? Updates are frequent and it can take a while for me to update the versions, create a pull request and then for it to get merged which leaves users on an outdated kernel for a while.

You just need to change the version variable in the build script and update the config (there likely won’t be much change due to us using LTS). You can be notified of new releases by watching the linux-hardened repo: Watchers · anthraxx/linux-hardened · GitHub

1 Like

kconfig-hardened-check and the KSPP recommended kernel settings have both been recently updated but there isn’t anything relevant to us (as we’ve already done them, they aren’t in our version or they’re for clang).

1 Like

I am not comfortable with hardened-kernel yet. I can’t give it as much time as it deserves. It’s still not having the maturity that I’ve set as a goal before recommending it to users of Whonix / Kicksecure. (Comparable to other Whonix packages.) See project status (written just today):

(And also improved hardened-kernel generally a bit.)

Will take time until these issues are solved.

None of the technical issues are not too hard to solve. Underlying issue are non-technical, lack of time and no current scaling issues of the Whonix project.

Automated test suite:

1 Like
1 Like

If I’m understanding this right, we can make the build script create ${working_folder}/packages, then move all the .debs there after compilation:


if ! [ -d "${packages_folder}" ]; then
  mkdir "${packages_folder}"

mv "${extracted_linux_kernel_sources_folder}/../linux-libc-dev_${version}-rt24-1_amd64.deb" "${packages_folder}/${kernel_config}-libc.deb"
mv "${extracted_linux_kernel_sources_folder}/../linux-headers-${version}-rt24_${version}-rt24-1_amd64.deb" "${packages_folder}/${kernel_config}-headers.deb"
mv "${extracted_linux_kernel_sources_folder}/../linux-image-${version}-rt24_${version}-rt24-1_amd64.deb"  "${packages_folder}/${kernel_config}.deb"

/etc/apt/sources.list.d/hardened-kernel-local.list would then contain:

deb [trusted=yes] file:/var/lib/hardened-kernel/hardened-vm-kernel/packages local main contrib non-free
deb [trusted=yes] file:/var/lib/hardened-kernel/hardened-host-kernel/packages local main contrib non-free

We then run apt update and install the kernel image via apt install? e.g.

apt update
apt install hardened-vm-kernel hardened-vm-kernel-headers hardened-vm-kernel-libc

Am I getting this right?

1 Like

Probably yes.

Yes but that folder cannot just contain packages as far as I know. It needs to be in a file structure that apt understands. I.e. APT repository metadata. To be created with reprepro.

Not sure this was thought or intended to say, just mentioning in case: by changing the filename such as linux-image-${version}-rt24_${version}-rt24-1_amd64.deb to hardened-vm-kernel.deb actually nothing happens. apt does “not much” use the file name for anything. The name of the package is derived from the Debian package metadata (/debian folder).

Getting apt to act on sudo apt install hardened-vm-kernel requries the Debian package metadata to use Package: hardened-vm-kernel somewhere. I don’t know yet how the Debian packaging of linux kernel works yet. Usually for packages (from other than linux there is a /debian folder in the source code repository that contains all Debian packaging related files. In case of the linux kernel it seems like that make deb-pkg somehow auto generates that /debian folder during the build process. I wouldn’t know the best approach yet.

  • Perhaps build the kernel image without using make deb-pkg and then use a /debian folder based on Debian’s Debian kernel team / linux · GitLab /debian folder (I speculate that one is better), or
  • Hack the environment variables / autogeneration code of Linux’s upstream make deb-pkg. (I speculate this way is worse.)

That auto generated /debian folder may or may not differ from the /debian folder for linux-image from

For educational / development / debugging purposes I’d suggest to experiment with packaging something easy first such as the hello package. Building that package from source. Maybe adding that package to a local APT repository. Other “easily” packaged packages might be genmkfile, helper-scripts, kloak, lkrg. (The software itself might be complex but the packaging process wasn’t the most hard level.)

1 Like

Can’t we just unpack the deb, edit it, then re-pack it?


ar x "${packages_folder}/${kernel_config}.deb"
tar xf "${packages_folder}/control.tar.xz"
str_replace "..." "..." "${packages_folder}/control"
tar cf ... ...
ar m ... ...
1 Like


1 Like
1 Like

Contacted Colin Childs @Phou through twitter DM.

since you’ve previously worked on coldkernel…
any chance to get you interested in GitHub - Kicksecure/hardened-kernel: Hardened kernel configuration optimized for virtual machines. - ?
not grsecurity but using GitHub - anthraxx/linux-hardened: Minimal supplement to upstream Kernel Self Protection Project changes. Features already provided by SELinux + Yama and archs other than multiarch arm64 / x86_64 aren't in scope. Only tags have stable history. Shared IRC channel with KSPP: #linux-hardening and a hardened kernel config
^ Patrick

What this project needs most is outreach. Getting developers interested that previously worked on packaging grsecurity, grsecurity installers, etc. Most simply gave up after grsecurity was gone. Very few know about the existence of GitHub - anthraxx/linux-hardened: Minimal supplement to upstream Kernel Self Protection Project changes. Features already provided by SELinux + Yama and archs other than multiarch arm64 / x86_64 aren't in scope. Only tags have stable history. Shared IRC channel with KSPP: #linux-hardening let alone hardened-kernel-config / GitHub - Kicksecure/hardened-kernel: Hardened kernel configuration optimized for virtual machines. -


I think it might be a good idea to create a large post detailing all of our recent security hardening work including security-misc, apparmor-profile-everything, hardened-kernel, sandbox-app-launcher, hardened_malloc, LKRG and tirdad and the issues they aim to fix, similar to The Problem with Security Guides and How We Can Fix It. It could have the potential to attract a lot of new people as it’s not just kernel stuff but also MAC, sandboxing, memory allocators etc.

I could write something up if you’re interested. A good title may be something like “Fixing the Desktop Linux Security Model”.

1 Like

Yes, very much so!

1 Like

How is Debian paste error?

1 Like

Looks really good already. I have to read more carefully, but I guess it will only be nitpicks from my side. You could also post the draft here:

Could you please convert

security vulnerabilities [1]


security vulnerabilities

Unless there is a reason not to do this?

or both

security vulnerabilities [1]?

I guess both ([number] style + forum links) would be good to - because then this can be re-posted on mailing lists.

tirdad is a kernel module that aims to prevent TCP Initial Sequence Number (ISN) based information leaks by randomizing the TCP ISNs [6]. This is more of anonymity feature than a security feature.

Did you see this security argument here?

GitHub - Kicksecure/tirdad: TCP ISN CPU Information Leak Protection. TCP Initial Sequence Numbers Randomization to prevent TCP ISN based CPU Information Leaks.

Could you please mention maybe SAK, login spoofing, the mostly sudo security theater and how multiple boot modes for better security: persistent user | live user | persistent secureadmin | persistent superadmin | persistent recovery mode would fix that?

Worth mentioning all Upcoming Security Enhancements?

Untrusted Root User

deactivate malware after reboot from non-root compromise

Mount Options Hardening

Disable SUID Binaries

Whonix is a security, privacy and anonymity focused Linux distribution. Recently, we’ve been focusing a lot on important security hardening measures and fixing architectural security issues within the desktop Linux security model.

Could you please make more clear that any desktop Linux distribution is affected?

1 Like

Most are part of security-misc so there’s not much reason to mention them separately. I extended the security misc section a bit and added your suggestions Debian paste error

1 Like

Btw the sandbox-app-launcher link is GitHub - Kicksecure/sandbox-app-launcher: An app launcher to start apps in a restrictive sandbox which doesn’t exist. Should I change it to GitHub - madaidan/sandbox-app-launcher: An app launcher to start apps in a restrictive sandbox or will you fork it?

1 Like