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.
Linux Kernel Driver DataBase: CONFIG_HW_RANDOM: Hardware Random Number Generator Core support 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 Linux Kernel Driver DataBase: CONFIG_COMEDI: Data acquisition support (comedi) is not popular indeed. Never heard before.
CONFIG_RTL8192U popular?
For baremetal yes, however it makes no sense for VM.
https://www.kernel.org/doc/html/latest/admin-guide/hw_random.html
The hw_random framework is software that makes use of a special hardware feature on your CPU or motherboard, a Random Number Generator (RNG).
The only things I can find about Intel/AMD RNGs are in the CPU.
Not sure. There may be tricks people can use to make it autoload but we can’t really be sure. Would be best to just remove unneeded modules.
Dunno. If it was popular, it probably wouldn’t be a staging driver.
Patrick Schleizer:
Hi Patrick,
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.
Quote Linux Kernel Driver DataBase: CONFIG_HW_RANDOM_VIA: VIA HW Random Number Generator support
This driver provides kernel-side support for the Random Number Generator hardware found on VIA based motherboards.
One good point:
If unsure, say Y.
Asked just now if that would be a good idea:
Got reply.
smuellerDD:
Am Dienstag, 25. Februar 2020, 07:36:52 CET schrieb Patrick Schleizer:
Hi Patrick,
We are using kernel command line
random.trust_cpu=offto distrust / not
credit randomness sourced from CPU’sRDRAND.
(rationale)Now we are wondering about the following kernel compile configuration
changes:Old:
CONFIG_HW_RANDOM=m CONFIG_HW_RANDOM_INTEL=m CONFIG_HW_RANDOM_AMD=m CONFIG_HW_RANDOM_VIA=mNew:
CONFIG_HW_RANDOM=y CONFIG_HW_RANDOM_INTEL=y CONFIG_HW_RANDOM_AMD=y CONFIG_HW_RANDOM_VIA=yWould that be a good idea?
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.(Presumption is: “don’t trust/credit hwrng such as RDRAND but mix it into
the randomness pool”.
([rationale](Entropy, Randomness, /dev/random vs /dev/urandom, Entropy Sources, Entropy Gathering Daemons, RDRAND
om)))Would that contradict
random.trust_cpu=off?As stated above, it would not contradict it as the noise source would be
completely different (dedicated hardware).Does
random.trust_cpu=offcover 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=nresult in disablingRDRAND? (I am not
suggesting to configureCONFIG_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.Ciao
Stephan
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
Just because Realtek in general is popular doesn’t mean the RTL8192U driver is. Realtek makes plenty of chips.
CONFIG_EFI_VARS might be good to disable in the host kernel. It exposes a lot of attack surface as it allows you to mess with EFI variables.
linux/Kconfig at master · torvalds/linux · GitHub
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.
CLIP OS disables this.
There are also the CONFIG_DEV_COREDUMP, CONFIG_WANT_DEV_COREDUMP and CONFIG_ALLOW_DEV_COREDUMP options.
linux/Kconfig at master · torvalds/linux · GitHub
These seem to add a “device coredump” thing regardless of CONFIG_COREDUMP (which we disable).
Also, instead of trying to patch out dmesg, we can try just disabling CONFIG_PRINTK.
madaidan via Whonix Forum:
Also, instead of trying to patch out dmesg, we can try just disabling
CONFIG_PRINTK.
I don’t think it’s a good since it makes debugging almost impossible.
Quote Linux Kernel Driver DataBase: CONFIG_PRINTK: Enable support for printk
This option enables normal printk support. Removing it eliminates most
of the message strings from the kernel image and makes the kernel more
or less silent. As this makes it very difficult to diagnose system
problems, saying N here is strongly discouraged.
⚓ T950 set kernel.printk sysctl to prevent kernel info leaks seems like a better way forward.
I reverted the revert. As per expert input
there is no indication of this being a bad idea. In other words
is now merged.
Merged but didn’t actually change something due to above.
We don’t have any real data. Can only speculate. A google search for the name of the wifi device plus “linux forum” brings up lots of search results. Search terms:
People are using these devices. Therefore I think it’s better to keep these modules for wifi devices.
That also shows that the approach of 1 kernel config for the host (and another 1 for all VMs) covering it all cannot be perfect. Either hardware support becomes more broken than Debian default (which is already not working for many people) or it’s not a minimal amount of kernel modules.
Maybe the Clip OS approach of generating the kernel config on the user’s system (?) would bring more optional results. But probably also at higher development and maintenance efforts. And even then we’d have to decide on a default which gets used when users boot the system for the very first time.
For hosts: Maybe kernel re-compilation could be done at first boot of system or during installation to be tailored for the system. But all of this is far fetched in future.
EFI can be used to backdoor a system. I don’t like it. Though Features/EFI - Fedora Project Wiki and dual boot - Can GRUB2 share the EFI system partition with Windows? - Unix & Linux Stack Exchange imply that this kernel config is required for EFI booting. We shouldn’t break EFI booting / EFI bootmanger upgrade. Can you test these things?
That’d be no different than patching out dmesg AFAIK. I guess the only advantage with patching it out is we can add a sysctl for superroot to change it at runtime.
That won’t prevent root from using dmesg.
It only seems to be required for installation. As long as grub isn’t installed while using hardened-kernel it should be alright?
There appears to be 2 ways to modify EFI variables. CONFIG_EFI_VARS and CONFIG_EFIVAR_FS.
linux/Kconfig at master · torvalds/linux · GitHub
From the kconfig, it looks like CONFIG_EFI_VARS is legacy.
madaidan via Whonix Forum:
It only seems to be required for installation.
We need reasonable certainties. Otherwise we’d produce stuff which is
later going to be unusable. EFI booting is hard on its own. Adding
disabling of kernel EFI config to the mix makes it even harder.
As long as grub isn’t installed while using hardened-kernel it should
be alright?
How would grub not be installed? It’s a default package in Debian,
Whonix, Kicksecure. You probably mean only required during
grub-install? Well, at some point one needs to run grub-install. For
example when booting a Whonix or Kicksecure Live ISO (to be created in
future) it would hopefully boot a hardened kernel. When then running the
installer, grub-install needs to function. Otherwise at that point
there would be a hard to debug and fix issue.
I see a lot other stuff more important before a hardened kernel can take
off or details such as EFI variables kernel config become a question.
I’d say better get it widely deployed first and then do fine tuning.
Otherwise if we ship something that doesn’t work for most users we end
up keeping using the standard kernel.