3 ms·
Could WireGuard use libjitterentropy (https://github.com/smuellerDD/jitterentropy-library https://github.com/smuellerDD/jitterentropy-library) to avoid this?
by swills 7y ago
Could WireGuard use libjitterentropy (https://github.com/smuellerDD/jitterentropy-library https://github.com/smuellerDD/jitterentropy-library) to avoid this?
- swills 7y agoSorry, WireGuard is in kernel, but jitterentropy may still be able to help: http://www.chronox.de/jent.html http://www.chronox.de/jent.html
- zx2c4 7y agoWireGuard 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.
- altfredd 7y agoI 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.