Messages in this thread | | | Date | Tue, 7 Jun 2022 14:21:55 +0200 | From | "Jason A. Donenfeld" <> | Subject | Re: [PATCH] random: defer use of bootloader randomness to random_init() |
| |
Hi Ard,
On Tue, Jun 07, 2022 at 02:15:27PM +0200, Ard Biesheuvel wrote: > Note that jump labels use asm() blocks, which are opaque to the > compiler, and so it is not guaranteed that codegen will be better than
I actually spent a lot of time looking at the codegen on a few platforms.
> > > - Why do we need to enable this static key so early? > > > > We don't need to enable it especially early. I've now sent three > > different approaches for deferring it until later and you suggested one. > > The first of mine is kind of ugly (checking static_key_initialized and > > such at different points). Your suggested one after that did the same > > but deferred into crng_reseed(), which I'm not a fan of. My second one > > is this patch, which is flawed for the reason you pointed out. But > > perhaps my third one is the right amount of simple and okay? That's the > > one I linked up top, [1]. Let me know what you think of that. > > > > My motivation for not wanting to defer it is that if the arch solution > > winds up being easy and straight forward (as it was for arm64), then it > > would be nice to not need to clutter up random.c as a result. > > If clutter is a concern, how about getting rid of the > execute_in_process_context() dance, and just use a late_initcall() > instead?
As I already explained in [1], this does not work. If the order is (A)(B), then all this will happen *after* the late init call.
[1] https://lore.kernel.org/lkml/Yp8oOH+9V336LrLk@zx2c4.com/
Jason
| |