CVE-2024-35875

In the Linux kernel, the following vulnerability has been resolved:

x86/coco: Require seeding RNG with RDRAND on CoCo systems

There are few uses of CoCo that don't rely on working cryptography and

hence a working RNG. Unfortunately, the CoCo threat model means that the

VM host cannot be trusted and may actively work against guests to

extract secrets or manipulate computation. Since a malicious host can

modify or observe nearly all inputs to guests, the only remaining source

of entropy for CoCo guests is RDRAND.

If RDRAND is broken -- due to CPU hardware fault -- the RNG as a whole

is meant to gracefully continue on gathering entropy from other sources,

but since there aren't other sources on CoCo, this is catastrophic.

This is mostly a concern at boot time when initially seeding the RNG, as

after that the consequences of a broken RDRAND are much more

theoretical.

So, try at boot to seed the RNG using 256 bits of RDRAND output. If this

fails, panic(). This will also trigger if the system is booted without

RDRAND, as RDRAND is essential for a safe CoCo boot.

Add this deliberately to be "just a CoCo x86 driver feature" and not

part of the RNG itself. Many device drivers and platforms have some

desire to contribute something to the RNG, and add_device_randomness()

is specifically meant for this purpose.

Any driver can call it with seed data of any quality, or even garbage

quality, and it can only possibly make the quality of the RNG better or

have no effect, but can never make it worse.

Rather than trying to build something into the core of the RNG, consider

the particular CoCo issue just a CoCo issue, and therefore separate it

all out into driver (well, arch/platform) code.

[ bp: Massage commit message. ]