Hi Jason, On 05/07/2022 15:18, Jason A. Donenfeld wrote: > 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. You're right, the buffering has the disadvantage, that the random data for the non-first callers are not fresh. But if we only want to have fresh data here, we should avoid this call in interrupt context completely (see below). > 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. It is true, that the performance of the instruction is not really relevant, but only for calls outside of an interrupt context. I did some ftrace logging for the s390_random_get_seed_long() calls, and - as you said - there are a few calls per minute. But there was also some repeating calls in interrupt context. On systems with a huge interrupt load, this can cause severe performance impacts. I've no concrete performance measurements at the moment, but - as I said - the trng instruction on s390 takes a lot of time and in interrupt context the interrupts are disabled for the complete runtime of the instruction. > 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. The optimization of the trng calls was not the main goal, but we (Harald and I) thought about how can we provide trng data to in-interrupt callers as well, without doing the trng instruction call in the interrupt context itself. At the moment, I don't see any possibility to do both, fresh data and prevent trng calls in interrupt context BUT provide trng data for in-interrupt-callers. But I'm always open for new ideas. If the data must be fresh, I would propose not to use any trng-generated data for in-interrupt callers. > > Jason -- Mit freundlichen Grüßen / Kind regards Holger Dengler -- IBM Systems, Linux on IBM Z Development dengler@xxxxxxxxxxxxx
