kernel recompilation for better hardening

Development
,
397

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=off to distrust / not
credit randomness sourced from CPU’s RDRAND.
(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=m

New:

CONFIG_HW_RANDOM=y
CONFIG_HW_RANDOM_INTEL=y
CONFIG_HW_RANDOM_AMD=y
CONFIG_HW_RANDOM_VIA=y

Would 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=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.

Ciao
Stephan

2 Likes