This is super helpful since other eyes review these things! Thanks a lot for such upstreaming efforts!
(To nitpick: not exactly upstreaming just yet but similar helpful in long run.)
CONFIG_DRM_VBOXVIDEO is a staging driver. Is this actually used in vbox guests?
3 posts were split to a new topic: VirtualBox Guest Additions
madaidan via Whonix Forum:
madaidan via Whonix Forum:
A bit time consuming to review. Requires upgrade to newer kernel,
And then do these changes break
Actually needs to be reverted. We would have to be sure if these sources of entropy would be trusted / credited.
I don’t see much advantage over built-in vs module anyhow? For something important as this, better just keep it as default as module?
Are these modules auto load? And when auto load, is this entropy source credited / trusted?
As for some patches, there is a portable and ready to use version of PAX_RAP, a
gcc plugin that implements forward and backword edge control flow integrity
sitting in the VMware Photon repo:
They have some other stuff too, like PAX_RANDKSTACK:
All their stuff is worth checking out:
Funny you should mention ClipOS. I remember when it first came out, since they
were using the grsecurity 4.9 patchset. They also had a bunch of cool patches,
although most of them got archived when they dropped grsecurity from their
primary repo. They also never switched to using my
dapper-secure-kernel-patchset-stable either, although its easy to see why,
since its difficult to trust some random developer with something security
critical as a kernel hardening patchset.
Anyway, I haven’t read much of the things they carry in their repos these days.
Its probably pretty good though.
Other things you can easily put into your kernel are the GRKERNSEC_CHROOT_*
features. Those patches are self contained and can be easily extracted from
a grsecurity patchset. They are low risk, stable, and provide good additional
hardening of chroots, although I suppose no one trusts the security of
chroots these days, and we all use namespaces instead.
Other than that, try and enable all the GCC plugins, and set lockdown to
confidentiality and integrity mode.
The vboxvideo module wasn’t removed. Read the pull request description.
This won’t break anything.
We distrust these for initial entropy (
CONFIG_RANDOM_TRUST_CPU). Being built-in/module doesn’t trust/credit it more.
The same advantage as building in the jitterentropy module. Entropy starts being generated earlier rather than need to wait for it to be loaded.
CONFIG_RANDOM_TRUST_CPU / random.trust_cpu is for CPU, not for hardware rng?
Ah, I assumed the HWRNG was in the CPU but it turns out these ones are on the motherboard (see https://github.com/torvalds/linux/blob/master/drivers/char/hw_random/Kconfig) so it is probably trusted.
Either way, the entropy would be trusted regardless if it’s built-in/module. The only difference is that being built-in means it generates entropy earlier.
For these might be better to load later than earlier. Or keep defaults Could even consider distrusting / not crediting. If that is even possible. Could even consider blacklisting. Requires more research.
How? It’d just be delaying entropy.
The “real” HWRNGs are the only ones that would need to be distrusted. virtio-rng isn’t an actual HWRNG.
The best solution seems to be to have them all built-in but distrust the real HWRNGs.
Btw can you merge the staging drivers pull request? I’m going to make more changes but they might conflict.
I think these HWRNGs actually are in the CPU.
In the kernel it’s only described as “AMD Random Number Generator” and the only things I can find about this RNG is in the CPU.
Hence, CONFIG_RANDOM_TRUST_CPU does distrust these HWRNGs and we can use them without worry.
Delay yes but also give better chance that initial entropy after boot is from more trustworthy sources. Or at least following what most are doing (compile as module). And not going a special way. The potential issues over weight the potential gain here.
Reverted for now until we have more input. For something as sensitive as this, shouldn’t move fast.
virtio-rng is non-controversial indeed. Built-in seems a good idea.
Need more time for review.
Wondering how much hardware support would break and how important these devices are. Breaking a popular wifi device would not be great (if that is the case).
Also the threat model. Is it mostly about preventing untrusted root from loading potentially vulnerable modules to exploit these?
It’s distrusted via CONFIG_RANDOM_TRUST_CPU anyway. See above. The HWRNGs seem to be in the CPU.
They aren’t popular. Hence why they’re staging drivers and not ordinary drivers. They might not even work anyway.
No, the modules can probably be auto-loaded too. These modules are low quality, are more likely to contain security vulnerabilities and likely won’t be used by an average user.
We need higher certainty here.
https://cateee.net/lkddb/web-lkddb/HW_RANDOM.html says motherboards, not CPUs:
The configuration item CONFIG_HW_RANDOM:
This driver provides kernel-side support for the Random Number Generator hardware found on Intel i8xx-based motherboards, AMD 76x-based motherboards, and
Autoload for those who have such hardware only or autoload thorough some kind of trick by anyone?
I guess for some this is true for sure such as https://cateee.net/lkddb/web-lkddb/COMEDI.html is not popular indeed. Never heard before.