[zx2c4]

WireGuard uses the correct kernel function, get_random_u32(). WireGuard does not use RdRand directly. WireGuard instead uses the proper kernel function for asking for a unsigned 32-bit number. The kernel implements get_random_u32() under the hood using a variety of backends for it. One of them is RdRand.

Other facilities in the kernel, such as ASLR, also use get_random_u32().

Many things in the kernel use get_random_u32(). That's the proper function to use.

When presented with this bug, the upstream kernel maintainers chose not to fix get_random_u32(), due to the availability (?) of microcode updates for AMD chips. That's not my decision. WireGuard is just a mere consumer of get_random_u32(), like all other modules. This is an upstream kernel bug.

[zaroth]

> That's not my decision.

So says a maintainer of WireGuard. HN is beautiful sometimes.

If RANDOM_TRUST_CPU is disabled, that will stop the kernel function from using RDRAND and avoid this issue for anyone using the ‘get_random_u32()’ function?

[dfox]

No. get_random_u32() simply returns result of RDRAND if RDRAND is available regardless of any runtime configuration. For me that is pretty significant issue, because it is documented as being based on separate kernel-only CSPRNG with somewhat specific security assumptions (complete with pretty large discussion in comments of random.c as to why would anybody want that weird thing)