Hacker News Reader

Could WireGuard use libjitterentropy (https://github.com/smuellerDD/jitterentropy-library) to avoid this?

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.

I imagine, that ASLR uses get_random_u32(), because it is needed during earliest phases in boot, before random pool is initialized. It might not necessarily be the proper function for making kernel random numbers — rather such function might not exist in Linux yet.

Sorry, WireGuard is in kernel, but jitterentropy may still be able to help: http://www.chronox.de/jent.html

Reply on news.ycombinator.com