One of the things that take up the longest compilation time are networking stuff which have mostly been untouched.
We should figure out exactly which networking and netfilter options we need and remove unused ones.
For example, I doubt we need things like IPVS, vsockets or CONFIG_NF_CONNTRACK_H323 which allows us to configure iptables rule for some VoIP protocol. There’s also a bunch of network packet schedulers, none of which are being used.
I tested it and compilation takes 77 minutes for me. This is still far too slow. We need to cut down more modules. Development would also greatly speed up if I could compile and test the kernel quicker.
Should CONFIG_SWAP be disabled? I don’t know Whonix’s stance on swap now that GitHub - Kicksecure/swap-file-creator: Adds encrypted swap file to the system - for better protection of locally stored data and to aid environments with low RAM. https://www.kicksecure.com/wiki/swap-file-creator is a thing.
The linux-hardened patches work flawlessly with the kernel sources from kernel.org but it has tons of errors with the debian kernel sources. It might be better to just use the sources from kernel.org and copy/paste the debian packaging from the debian sources.
Actually, we won’t even need to do that. The make deb-pkg command is what generates the debian folder.
I don’t know what CONFIG_SWAP does but swap file is unfortunately required due to swap - swap file - Whonix-Gateway freezing during apt-get dist-upgrade - encrypted swap-file-creator. I preferred if avoidable. Not nice since it makes the gateway boot slower.
CONFIG_SWAP is what it sounds like, support for swap files.
madaidan via Whonix Forum:
The linux-hardened patches work flawlessly with the kernel sources from kernel.org but it has tons of errors with the debian kernel sources. It might be better to just use the sources from kernel.org and copy/paste the debian packaging from the debian sources.
Yes. Could we even git clone linux-hardened and copy over Debian
packaging files? That previously failed for some reason?
I guess the Debian packaging files would not change much if kernel
sources are updated but I could be ignorant about some complexity.
Does linux-hardened offer signed git commits or even better signed git
tags? If yes, that would be possible (a secure way).
We would need to understand why Debian patches the Linux kernel. They
have a ton of patches. The list of patches is here:
Could you have a look please?
It’s far easier just to download a tarball from kernel.org and apply the patch. That’s how it’s meant to be done.
We don’t even need to copy over anything:
Just running make deb-pkg in the directory that contains the kernel source is enough.
All commits are signed Commits · anthraxx/linux-hardened · GitHub
Most are fixes or extra features. There are a few security features but these are all part of linux-hardened anyway.
I’ve looked through them and none seem important for us.
There’s a short description of them at debian/patches/series · master · Debian kernel team / linux · GitLab
I got the 4.19.91 kernel source from kernel.org, applied the linux-hardened patch, compiled using make deb-pkg and it works perfectly.
Should we be using LTS or stable kernels?
Probably stable more secure as not all security bugs are properly backported. Don’t have reference for that at hand but @HulaHoop might have.
Sounds awesome!
In theory (without knowing where to find documentation or source code) It could e swap partition or something different too, unrelated to swap files.
debian/patches/debian/version.patch · master · Debian kernel team / linux · GitLab might hint that environment variables are supported such as $DISTRIBUTOR' and $DISTRIBUTION_VERSION which influence how kernel packages would be named.
What is CONFIG_NET_EGRESS?
You could use “make tinyconfig” which creates a minimal non bootable kernel so you can estimate the lowest possible compilation time for your setup. If it still takes an hour or so then cutting out more modules maybe won’t help that much. Recompiling the cloud kernel could also give a good estimate on what to expect from a stripped down kernel.
It’s maybe not a good estimate but iirc the tinyconfig is around 20-30kb while the cloud kernel config for Debian is around 90kb. The latter one should work for the average desktop system when some GUI relevant stuff is added.
Sure but stable kernels have newer code and more attack surface.
The real “hard truth” about Linux kernel security is that there’s no such thing as a free lunch. Keeping up to date on the latest upstream kernel will generally net all the bug fixes that have been created thus far, but with it of course brings completely new features, new code, new bugs, and new attack surface. The majority of vulnerabilities in the Linux kernel are ones that have been released just recently, something any honest person active in kernel development can attest to.
Although, stable kernels do have more hardening features.
It’s a hard decision.
LTS kernels have less hardening features and not all bug fixes are backported but it has less attack surface and potentially less chance of having bugs.
Stable kernels have more hardening features and all bug fixes but more attack surface and more bugs.
We should look into that. We should add a -hardened suffix or something to differentiate between our kernel and normal kernels.
Dunno. Was automatically disabled with make. The kernel devs don’t seem to think it’s important enough to warrant a description linux/net/Kconfig at master · torvalds/linux · GitHub
Thanks! I didn’t know about this. I’ll test it later.
madaidan via Whonix Forum:
Sure but stable kernels have newer code and more attack surface.
grsecurity - The Truth about Linux 4.6
The real “hard truth” about Linux kernel security is that there’s no such thing as a free lunch. Keeping up to date on the latest upstream kernel will generally net all the bug fixes that have been created thus far, but with it of course brings completely new features, new code, new bugs, and new attack surface. The majority of vulnerabilities in the Linux kernel are ones that have been released just recently, something any honest person active in kernel development can attest to.
Although, stable kernels do have more hardening features.
It’s a hard decision.
LTS kernels have less hardening features and not all bug fixes are backported but it has less attack surface and potentially less chance of having bugs.
Stable kernels have more hardening features and all bug fixes but more attack surface and more bugs.
Let’s use LTS kernels instead. For more stability. Something good that
works is better than something “perfect” constantly breaking.
lkrg-users - LIST HASH IS DIFFERENT - nf_nat / nf_conntrack Linux version 5.3.0-0 reminds me,
keeping up with kernel issues shouldn’t develop into most time spend on.