From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 1452CC43334 for ; Tue, 7 Jun 2022 10:42:05 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S241282AbiFGKmD (ORCPT ); Tue, 7 Jun 2022 06:42:03 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:56748 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S241271AbiFGKmB (ORCPT ); Tue, 7 Jun 2022 06:42:01 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 0F3EAEC3FE for ; Tue, 7 Jun 2022 03:42:00 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 9AE31614F0 for ; Tue, 7 Jun 2022 10:41:59 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 26FE7C34114; Tue, 7 Jun 2022 10:41:58 +0000 (UTC) Authentication-Results: smtp.kernel.org; dkim=pass (1024-bit key) header.d=zx2c4.com header.i=@zx2c4.com header.b="mFaH/g2s" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zx2c4.com; s=20210105; t=1654598516; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=nsqtTGmAdgvPQY41JLIrBhYMeB3kcIK6Q2atSXJiIPY=; b=mFaH/g2sglSIVwfgFHaPRRVnox92qapr5MYI9HlZVi+JwOlegrhctlq1M6ySDNXVt6kV97 RKI2qCPNA7hRq9sN/NWnjFX8Yw0tLDXquu4N5fAYJ3r03Ow4gg+N2O1esw8gdHTmB2hj1A 6kfe6dVBC0hOnEV1g8+mBoXZwsuooVg= Received: by mail.zx2c4.com (ZX2C4 Mail Server) with ESMTPSA id c45f5b9a (TLSv1.3:AEAD-AES256-GCM-SHA384:256:NO); Tue, 7 Jun 2022 10:41:55 +0000 (UTC) Date: Tue, 7 Jun 2022 12:41:52 +0200 From: "Jason A. Donenfeld" To: Ard Biesheuvel Cc: linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, Stephen Boyd , Catalin Marinas , Russell King , Arnd Bergmann , Phil Elwell Subject: Re: [PATCH] random: do not use jump labels before they are initialized Message-ID: References: <20220607100210.683136-1-Jason@zx2c4.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hey again, On Tue, Jun 07, 2022 at 12:28:08PM +0200, Jason A. Donenfeld wrote: > 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 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. Just thinking about this a bit more, I should note that this is not the first problem caused by EFI/DT doing its thing mega early in the boot process. Dominik and I fixed up what felt like endless bugs all of basically that same form back in January. Before it mostly had to do with workqueues not being available yet. Now it has to do with jump labels. So in thinking about how to fix this, the two approaches thus far discussed are: 1. initialize jump labels earlier, e.g. the arm64 patch (and proposed arm32 patch). 2. defer the static key enabling until later, e.g. this patch. As a third, I could just defer doing anything with the bootloader seed until random_init(). This might actually be the simplest solution... I'll sketch something out. A downside, which might be sort of significant, is that a few odd things actually use randomness before random_init() is called. So these would miss out on having that seed. I'll have to look what exactly to see if we're actually getting anything real out of that. Jason