CVE-2024-35875

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> x86/coco: Require seeding RNG with RDRAND on CoCo systems<br /> <br /> There are few uses of CoCo that don&amp;#39;t rely on working cryptography and<br /> hence a working RNG. Unfortunately, the CoCo threat model means that the<br /> VM host cannot be trusted and may actively work against guests to<br /> extract secrets or manipulate computation. Since a malicious host can<br /> modify or observe nearly all inputs to guests, the only remaining source<br /> of entropy for CoCo guests is RDRAND.<br /> <br /> If RDRAND is broken -- due to CPU hardware fault -- the RNG as a whole<br /> is meant to gracefully continue on gathering entropy from other sources,<br /> but since there aren&amp;#39;t other sources on CoCo, this is catastrophic.<br /> This is mostly a concern at boot time when initially seeding the RNG, as<br /> after that the consequences of a broken RDRAND are much more<br /> theoretical.<br /> <br /> So, try at boot to seed the RNG using 256 bits of RDRAND output. If this<br /> fails, panic(). This will also trigger if the system is booted without<br /> RDRAND, as RDRAND is essential for a safe CoCo boot.<br /> <br /> Add this deliberately to be "just a CoCo x86 driver feature" and not<br /> part of the RNG itself. Many device drivers and platforms have some<br /> desire to contribute something to the RNG, and add_device_randomness()<br /> is specifically meant for this purpose.<br /> <br /> Any driver can call it with seed data of any quality, or even garbage<br /> quality, and it can only possibly make the quality of the RNG better or<br /> have no effect, but can never make it worse.<br /> <br /> Rather than trying to build something into the core of the RNG, consider<br /> the particular CoCo issue just a CoCo issue, and therefore separate it<br /> all out into driver (well, arch/platform) code.<br /> <br /> [ bp: Massage commit message. ]