Hi Holger, On Tue, Jul 05, 2022 at 01:27:12PM +0200, Holger Dengler wrote: > The trng instruction is very expensive and has a constant runtime for > getting 0 to 32 bytes of (conditioned) true random data. Calling trng for > in arch_get_random_seed_long() for each 8 bytes is too time-consuming, > especially if it is called in interrupt context. > > This implementation buffers the trng data and deliver parts of it to the This patch seems to be repeating the same mistake I just cleaned up. Specifically, an advantage of a CPU RNG is that it can always provide *fresh* entropy, so that if, say, the system state is dumped, the CPU will continue to provide fresh new uncompromised values. When you buffer those values, they cease to be fresh. But more realistically, have you benchmarked this and seen that it's actually required? These functions are called once at boot, and then when the RNG is reseeded, which happens around once a minute. That's pretty darn rare. When you consider all the cycles that are completed over the course of a minute, whatever the cost of the TRNG is seems pretty negligible. So anyway, maybe it'd be best to look at the "big picture" problem you want to solve, rather than what looks to me like an attempt to solve a problem that doesn't exist. Or maybe it does? If so, I'd be interested to know when and how and where and such. Jason
