From: "Jason A. Donenfeld" <Jason@zx2c4.com> To: Ard Biesheuvel <ardb@kernel.org> Cc: linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, Stephen Boyd <swboyd@chromium.org>, Catalin Marinas <catalin.marinas@arm.com>, Russell King <linux@armlinux.org.uk>, Arnd Bergmann <arnd@arndb.de>, Phil Elwell <phil@raspberrypi.com> Subject: Re: [PATCH] random: do not use jump labels before they are initialized Date: Tue, 7 Jun 2022 12:28:08 +0200 [thread overview] Message-ID: <Yp8oOH+9V336LrLk@zx2c4.com> (raw) In-Reply-To: <CAMj1kXEAuh-tokcqvKCQF5Vq+jZKj4ZM=PyGaHKapXPJKVyOrg@mail.gmail.com> Hi Ard, On Tue, Jun 07, 2022 at 12:13:29PM +0200, Ard Biesheuvel wrote: > Hi Jason, > > On Tue, 7 Jun 2022 at 12:04, Jason A. Donenfeld <Jason@zx2c4.com> wrote: > > > > [ I would like to pursue fixing this more directly first before actually > > merging this, but I thought I'd send this to the list now anyway as a > > the "backup" plan. If I can't figure out how to make headway on the > > main plan in the next few days, it'll be easy to just do this. ] > > > > What more direct fix did you have in mind here? A non-broken version of https://lore.kernel.org/lkml/20220603121543.360283-1-Jason@zx2c4.com/ As I mentioned in https://lore.kernel.org/lkml/Yp8kQrBgE3WVqqC5@zx2c4.com/ , I would like a few days to see if there's some trivial way of not needing that on arm32. If it turns out to be easy, then I'd prefer the direct fix akin to the arm64 one. If it turns out to be not easy, then I'll merge the backup commit. > > diff --git a/drivers/char/random.c b/drivers/char/random.c > > index 4862d4d3ec49..f9a020ec08b9 100644 > > --- a/drivers/char/random.c > > +++ b/drivers/char/random.c > > @@ -650,7 +650,8 @@ static void __cold _credit_init_bits(size_t bits) > > > > if (orig < POOL_READY_BITS && new >= POOL_READY_BITS) { > > crng_reseed(); /* Sets crng_init to CRNG_READY under base_crng.lock. */ > > - execute_in_process_context(crng_set_ready, &set_ready); > > + if (static_key_initialized) > > + execute_in_process_context(crng_set_ready, &set_ready); > > Can we just drop this entirely, and rely on the hunk below to set the > static key? What justifies having two code paths that set the static > key in different ways on different architectures? No, we can't. The hunk below (A) is called from init/main.c some time after jump_label_init(). The hunk above (B) is called whenever we reach the 256-bit mark. The order is (B)(A) on machines that get seeded from efi or device tree. The order is (A)(B) on all other machines, which reach the 256-bit mark at "some point"... could be after a second, a minute, whenever enough estimated entropy has been accounted. Jason
WARNING: multiple messages have this Message-ID (diff)
From: "Jason A. Donenfeld" <Jason@zx2c4.com> To: Ard Biesheuvel <ardb@kernel.org> Cc: linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, Stephen Boyd <swboyd@chromium.org>, Catalin Marinas <catalin.marinas@arm.com>, Russell King <linux@armlinux.org.uk>, Arnd Bergmann <arnd@arndb.de>, Phil Elwell <phil@raspberrypi.com> Subject: Re: [PATCH] random: do not use jump labels before they are initialized Date: Tue, 7 Jun 2022 12:28:08 +0200 [thread overview] Message-ID: <Yp8oOH+9V336LrLk@zx2c4.com> (raw) In-Reply-To: <CAMj1kXEAuh-tokcqvKCQF5Vq+jZKj4ZM=PyGaHKapXPJKVyOrg@mail.gmail.com> Hi Ard, On Tue, Jun 07, 2022 at 12:13:29PM +0200, Ard Biesheuvel wrote: > Hi Jason, > > On Tue, 7 Jun 2022 at 12:04, Jason A. Donenfeld <Jason@zx2c4.com> wrote: > > > > [ I would like to pursue fixing this more directly first before actually > > merging this, but I thought I'd send this to the list now anyway as a > > the "backup" plan. If I can't figure out how to make headway on the > > main plan in the next few days, it'll be easy to just do this. ] > > > > What more direct fix did you have in mind here? A non-broken version of https://lore.kernel.org/lkml/20220603121543.360283-1-Jason@zx2c4.com/ As I mentioned in https://lore.kernel.org/lkml/Yp8kQrBgE3WVqqC5@zx2c4.com/ , I would like a few days to see if there's some trivial way of not needing that on arm32. If it turns out to be easy, then I'd prefer the direct fix akin to the arm64 one. If it turns out to be not easy, then I'll merge the backup commit. > > diff --git a/drivers/char/random.c b/drivers/char/random.c > > index 4862d4d3ec49..f9a020ec08b9 100644 > > --- a/drivers/char/random.c > > +++ b/drivers/char/random.c > > @@ -650,7 +650,8 @@ static void __cold _credit_init_bits(size_t bits) > > > > if (orig < POOL_READY_BITS && new >= POOL_READY_BITS) { > > crng_reseed(); /* Sets crng_init to CRNG_READY under base_crng.lock. */ > > - execute_in_process_context(crng_set_ready, &set_ready); > > + if (static_key_initialized) > > + execute_in_process_context(crng_set_ready, &set_ready); > > Can we just drop this entirely, and rely on the hunk below to set the > static key? What justifies having two code paths that set the static > key in different ways on different architectures? No, we can't. The hunk below (A) is called from init/main.c some time after jump_label_init(). The hunk above (B) is called whenever we reach the 256-bit mark. The order is (B)(A) on machines that get seeded from efi or device tree. The order is (A)(B) on all other machines, which reach the 256-bit mark at "some point"... could be after a second, a minute, whenever enough estimated entropy has been accounted. Jason _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2022-06-07 10:28 UTC|newest] Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top 2022-06-07 10:02 [PATCH] random: do not use jump labels before they are initialized Jason A. Donenfeld 2022-06-07 10:02 ` Jason A. Donenfeld 2022-06-07 10:13 ` Ard Biesheuvel 2022-06-07 10:13 ` Ard Biesheuvel 2022-06-07 10:28 ` Jason A. Donenfeld [this message] 2022-06-07 10:28 ` Jason A. Donenfeld 2022-06-07 10:41 ` Jason A. Donenfeld 2022-06-07 10:41 ` Jason A. Donenfeld 2022-06-07 10:56 ` Ard Biesheuvel 2022-06-07 10:56 ` Ard Biesheuvel 2022-06-07 11:04 ` Jason A. Donenfeld 2022-06-07 11:04 ` Jason A. Donenfeld 2022-06-07 11:10 ` Ard Biesheuvel 2022-06-07 11:10 ` Ard Biesheuvel 2022-06-07 11:35 ` Jason A. Donenfeld 2022-06-07 11:35 ` Jason A. Donenfeld 2022-06-07 12:03 ` Ard Biesheuvel 2022-06-07 12:03 ` Ard Biesheuvel 2022-06-07 12:16 ` Jason A. Donenfeld 2022-06-07 12:16 ` Jason A. Donenfeld 2022-06-07 12:21 ` Ard Biesheuvel 2022-06-07 12:21 ` Ard Biesheuvel 2022-06-08 8:24 ` Ard Biesheuvel 2022-06-08 8:24 ` Ard Biesheuvel
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=Yp8oOH+9V336LrLk@zx2c4.com \ --to=jason@zx2c4.com \ --cc=ardb@kernel.org \ --cc=arnd@arndb.de \ --cc=catalin.marinas@arm.com \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux@armlinux.org.uk \ --cc=phil@raspberrypi.com \ --cc=swboyd@chromium.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.