Messages in this thread |  | | From | "Jason A. Donenfeld" <> | Date | Mon, 7 Dec 2020 15:27:50 +0100 | Subject | Re: [PATCH] random: avoid arch_get_random_seed_long() when collecting IRQ randomness |
| |
Hi Ard,
On Tue, Dec 1, 2020 at 1:24 PM Ard Biesheuvel <ardb@kernel.org> wrote: > > > > is implemented. In most cases, these are special instructions, but in > > > > some cases, such as on ARM, we may want to back this using firmware > > > > calls, which are considerably more expensive.
This seems fine. But I suppose I'm curious to learn more about what you have in mind for ARM. We've been assuming that arch_get_random is not horribly expensive. Usually external RNGs that are horribly expensive separate hardware take a different route and aren't hooked into arch_get_random. When you say "we may want to back this using firmware", does that mean it hasn't happened yet, and you're in a position to direct the design otherwise? If so, would it be reasonable to take a different route with that hardware, and keep arch_get_random for when it's actually implemented by the hardware? Or are there actually good reasons for keeping it one and the same?
On the other hand, rdrand on intel is getting slower and slower, to the point where we've removed it from a few places that used to use it. And I don't see anything terribly wrong with removing the extra call in this path here. So need be, I'll offer my Reviewed-by. But I wanted to get an understanding of the fuller story first.
Jason
|  |