On Fri, Oct 18, 2019 at 4:42 PM Jörn Engel <jo...@purestorage.com> wrote:
>
> We can generate entropy on almost any CPU, even if it doesn't provide a
> high-resolution timer for random_get_entropy(). As long as the CPU is
> not idle, it changed the register file every few cycles. As long as the
> ALU isn't fully synchronized with the timer, the drift between the
> register file and the timer is enough to generate entropy from.
> static void entropy_timer(struct timer_list *t)
> {
> + struct pt_regs *regs = get_irq_regs();
> +
> + /*
> + * Even if we don't have a high-resolution timer in our system,
> + * the register file itself is a high-resolution timer. It
> + * isn't monotonic or particularly useful to read the current
> + * time. But it changes with every retired instruction, which
> + * is enough to generate entropy from.
> + */
> + mix_pool_bytes(&input_pool, regs, sizeof(*regs));
Ok, so I still like this conceptually, but I'm not entirely sure that
get_irq_regs() works reliably in a timer. It's done from softirq
TIMER_SOFTIRQ context, so not necessarily _in_ an interrupt.
Now, admittedly this code doesn't really need "reliably". The odd
occasional hickup would arguably just add more noise. And I think the
code works fine. get_irq_regs() will return a pointer to the last
interrupt or exception frame on the current CPU, and I guess it's all
fine. But let's bring in Thomas, who was not only active in the
randomness discussion, but might also have stronger opinions on this
get_irq_regs() usage.
Thomas, opinions? Using the register state (while we're doing the
whole entropy load with scheduling etc) looks like a good source of
high-entropy data outside of just the TSC, so it does seem like a very
valid model. But I want to run it past more people first, and Thomas
is the obvious victim^Wchoice.
Linus
