5 ms·
WireGuard uses the correct kernel function, get_random_u32(). WireGuard does not use RdRand directly. WireGuard instead uses the proper kernel function for aski
by zx2c4 7y ago
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 7y ago> 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 7y agoNo. 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)
- dingo_bat 7y agoIf you know that get_random_u32() is catastrophically broken on some systems, it is your decision to not mitigate for that. Especially if your app's critical functionality relies on said function. At the very least the user should know their VPN is insecure or something.
- deleted 7y ago[deleted]