Re: [linus:master] [lib/crypto] e5046823f8: stress-ng.urandom.ops_per_sec 4.3% regression
"Jason A. Donenfeld" <[email protected]> Thu, 16 Apr 2026 02:45:43 +0200
| Newsgroups | dev.linux.lists.oe-lkp,org.kernel.vger.linux-crypto |
|---|---|
| Message-ID | <CAHmME9q1UVnfEwyXL_Gi8xtRJ3pNhJ55h40nV1gtfQJ4zwt9Og@mail.gmail.com> |
On Wed, Apr 15, 2026 at 7:47 PM Eric Biggers <[email protected]> wrote: > > [+Cc Jason and Ted] > > On Wed, Apr 15, 2026 at 04:45:48PM +0800, kernel test robot wrote: > > > > > > Hello, > > > > kernel test robot noticed a 4.3% regression of stress-ng.urandom.ops_per_sec on: > > > > > > commit: e5046823f8fa3677341b541a25af2fcb99a5b1e0 ("lib/crypto: chacha: Zeroize permuted_state before it leaves scope") > > https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git master > > This commit fixed the forward secrecy of the RNG, so it needed to go in. > > For large RNG requests, we could get most of this performance back by > refactoring the chacha20_block() API to move the allocation of the > temporary state array into the caller. > > We could also get much better performance than before by using the > architecture-optimized ChaCha20 code instead of the generic ChaCha20 > code. > > However, neither would be a simple change. I saw this commit when you were making it and also benched it and it didn't seem like a big deal. (Otherwise I would have piped up or tried to come up with a different solution.) For a while, I was thinking that arch-optimized code in random.c would be neat, but with getrandom() being in the vDSO, we already get architecture-optimized code there, by necessity. So I think practically speaking, this is not a big deal. I had also looked into what happens to that stack in the context of the RNG, and it gets pretty quickly corrupted (and remember, you don't need to erase all of it for it to become practically non-invertible). But why should we play games with that sort of thing? Zeroing is the right move. Jason