* Linus Torvalds: > On Tue, Jan 3, 2023 at 11:35 AM Jason A. Donenfeld <Jason@xxxxxxxxx> wrote: >> >> I don't think this is about micro-optimization. Rather, userspace RNGs >> aren't really possible in a safe way at the moment. > > "Bah, humbug", to quote a modern-time philosopher. > > It's humbug simply because it makes two assumptions that aren't even valid: > > (a) that you have to do it in user space in the first place > > (b) that you care about the particular semantics that you are looking for > > The thing is, you can just do getrandom(). It's what people already > do. Problem solved. We are currently doing this in glibc for our arc4random implementation, after Jason opposed userspace buffering. If chrony is recompiled against the glibc version of arc4random (instead of its OpenBSD compat version, which uses userspace buffering), the result is a 25% drop in NTP packet response rate: | The new arc4random using getrandom() seems to have a significant | impact on performance of chronyd operating as an NTP server. On an | Intel E3-1220 CPU, I see that the maximum number of requests per | second dropped by about 25%. That would be an issue for some public | NTP servers. arc4random is too slow <https://sourceware.org/bugzilla/show_bug.cgi?id=29437> This is *not* “arc4random is 25% slower”, it is the measured overall impact on server performance. Historically, the solution space for getrandom and arc4random are slightly different. The backronym is “A Replacement Call For random”, i.e., you should be able to use arc4random without worrying about performance. I don't expect cryptographic libraries to turn to arc4random to implement their random number generators, and that programmers that use low-level OpenSSL primitives (for example) keep calling RAND_bytes instead of arc4random because it is available to them. We did these changes on the glibc side because Jason sounded very confident that he's able to deliver vDSO acceleration for getrandom. If that fails to materialize, we'll just have to add back userspace buffering in glibc. At least we can get process fork protection via MADV_WIPEONFORK, solving a real problem with the usual arc4random compat implementation. (The OpenBSD mechanism for this is slightly different.) We won't get VM fork protection or forward secrecy against ptrace. But the latter is rather speculative anyway because if you can do ptrace once, you can likely do ptrace twice, the first time patching the process to remove forward secrecy. There is a real gap for VM forks, but I'm not sure how much that matters in practice. Live migration has to be implemented in such a way that this isn't observable (otherwise TCP connections etc. would break), and long-term keys probably shouldn't be generated under virtualization anyway. Thanks, Florian
