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:
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.
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.
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.
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?
Would it be useful for our upcoming hardened-kernel / or generally to enable kernel config options CONFIG_CRYPTO_ANSI_CPRNG? (CONFIG_CRYPTO_ANSI_CPRNG=y)
This cipher is not really relevant any more - it is the ANSI X9.31 Appendix A2.4 RNG. The SP800-90A DRBGs are superior to the ANSI equivalent due to covering reseed requirements and similar. I see no reason to have that RNG enabled. Ciao Stephan
How would I know if popular or not?
Yes, makes little sense in VM indeed.
(I wouldn’t say no sense at all maybe one day Whonix-Workstation could serve as a torified WiFi hotspot but since that doesn’t exist it is not important enough to consider.)
CONFIG_HW_RANDOM_VIA (was included in pull request) is in the motherboard.
For starters, this is the hardware RNG framework making hardware RNGs
accessible via /dev/hwrand (code residing in drivers/char/hw_random).
The Intel RNG is a different RNG than RDRAND, but I am not fully sure which
hardware component would provide it (I guess some form of chipset that even
provides the QAT hardware crypto system).
If a HW RNG driver sets the struct hwrng->quality integer (which defines that
it provides entropy), the HW RNG framework will deliver entropy via
add_hwgenerator_randomness to /dev/random. Otherwise the /dev/random is not
affected by the HW RNG framework and its drivers.
Just do a grep quality in the drivers dir to see which drivers set a value and
thus would increase the entropy in /dev/random. Then decide for yourself
whether you want that.
As stated above, it would not contradict it as the noise source would be
completely different (dedicated hardware).
Does random.trust_cpu=off cover hardware random generators that are
located at the motherboard and not inside the CPU? (CONFIG_HW_RANDOM_VIA
says it is on the motherboard.)
No.
Is CONFIG_HW_RANDOM_INTEL “same as” RDRAND?
No, see above.
In other words, would CONFIG_HW_RANDOM_INTEL=n result in disabling RDRAND? (I am not
suggesting to configure CONFIG_HW_RANDOM_INTEL=n. This is just for better
understanding.)
My worry is that by having these hardware random generators load earlier
than the module could be load could result in the initial random seeding to
be more likely compromised if these hardware randomness generators are
flawed / predictable / backdoored.
Anecdotally I am seeing Realtek Wifi in a bunch of laptops across different brands.
Also Wikipedia indicates it has major marketshare though those stats are a bit dated :
Notable Realtek products include 10/100M Ethernet controllers (with a global market share of 70% as of 2003) and audio codecs (AC’97 and Intel HD Audio), where Realtek had a 50% market share in 2003 and a 60% market share in 2004, primarily concentrated in the integrated OEM on-board audio market-segment.[3] As of 2013 the ALC892 HD Audio codec and RTL8111 Gigabit Ethernet chip have become particular OEM favorites
There have been cases of people bricking their computers by accidentally deleting EFI variables. An attacker might be able to do far more by writing specific things to them.