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 bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 3D0DCC433EF for ; Tue, 7 Jun 2022 12:16:58 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:Cc:To:Subject:Message-ID:Date:From: In-Reply-To:References:MIME-Version:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=aU1EKWJrmYS/9SEWxmD5FT8uWJcmjnNo2MKHyzK/OoI=; b=vYI6Q8T8d7I3yU AIINvNNJrQF9doDnhC1FcMKGhoGyUJTmF9c6rN64G1o5t6FBgxfXTOlA8Yp/M84RX9h/LNA9CKX6Y xsKwMxxzBDRweY+lcT6KAiYXvenI5t3CjHTIQ+307U1GZGNveKdBORx5PH48Sv4+QTOPTxFDuHTqa +wm/O7asbpVEycDoPppcM0GJSnAJVY7PEmePIvTR8hvp5naB/Ch6yTymTJRQtmo+2K9q6B483J0+Z CZN275VLWrpugXHnFoyGO3atayxEeEzG8Qvw5WrAYQPvsJV+r/N/zyIWxtO1A7uhym3ThmAqf7Q4/ Ad3Fco/uHC1lztuzW68g==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1nyY7g-007HFE-Lp; Tue, 07 Jun 2022 12:15:48 +0000 Received: from dfw.source.kernel.org ([139.178.84.217]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1nyY7b-007HDW-5o for linux-arm-kernel@lists.infradead.org; Tue, 07 Jun 2022 12:15:45 +0000 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 7288E6176F for ; Tue, 7 Jun 2022 12:15:42 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 69157C3411F for ; Tue, 7 Jun 2022 12:15:41 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1654604141; bh=Jb9E0V2zg2oPVNPxcUTvoa/A+aVMyp1PhGwqF1vtsog=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=fbqSrlekrNTZZVmXei9TMPFP2HSnfbEwdG0PIZTrBF4K29pMVDTefdgYIYqiEeK9E nv9ppX0IUL1VP5ierwoJfn3eA5mckkjnMMP9+Ry0tYIxyB53SAiDGydGgka4Ggh82x 2C1iHhk3ZyxQqTuDh/VuaKn5/IEYn2h+XMKSLPITK6IZB0WXUzTUWuxkEkjQ5w+vNg lA1t064oS5mvwNkvkrTVyT/uQo/8DpGG0/GBfZGSFYLRW/s9UFjyxUCLNe7f9eon9f LbBYdtwzP2lEZtN/gyD61GDcGielcg/MYCAJ6fO6+eWAL3QUNWesLmotwjCUtGAkH7 eqnpY2tI0G1Gw== Received: by mail-oa1-f53.google.com with SMTP id 586e51a60fabf-f2e0a41009so22904534fac.6 for ; Tue, 07 Jun 2022 05:15:41 -0700 (PDT) X-Gm-Message-State: AOAM530rBTA1f/9QMJE2r8BDeoQek0JwoB91yRFPeL7mpgjMi6F8uH9m Gv5CnGSMVsx41DXlBQDKT5bVg5HIVAJiP7PYSOQ= X-Google-Smtp-Source: ABdhPJyavVbwzHeLyjFiqXkE+r1dLErK39HgrscOo4TKX+8oeK+bEPg70+jChjQ3whGnBB0SgWrJPTjeoAfvU7UKY0U= X-Received: by 2002:a05:6870:eaa5:b0:da:b3f:2b45 with SMTP id s37-20020a056870eaa500b000da0b3f2b45mr35027420oap.228.1654604140393; Tue, 07 Jun 2022 05:15:40 -0700 (PDT) MIME-Version: 1.0 References: <20220607111514.755009-1-Jason@zx2c4.com> In-Reply-To: From: Ard Biesheuvel Date: Tue, 7 Jun 2022 14:15:27 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH] random: defer use of bootloader randomness to random_init() To: "Jason A. Donenfeld" Cc: linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, Stephen Boyd , Catalin Marinas , Russell King , Arnd Bergmann , Phil Elwell X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220607_051543_392902_918D6BDC X-CRM114-Status: GOOD ( 40.58 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Tue, 7 Jun 2022 at 14:05, Jason A. Donenfeld wrote: > On Tue, Jun 07, 2022 at 01:55:37PM +0200, Ard Biesheuvel wrote: > > This is not going to work, I'm afraid - please see below. > > > > The next line says it all, really: the seed is in a firmware table > > somewhere, and only gets mapped temporarily here. Note that we cannot > > copy it either, as we are running way before we have discovered where > > RAM is to begin with. > > Oh, darn. Okay. The v2 might be a bit more palpable then. It mixes > immediately, but defers crediting: > > [1] https://lore.kernel.org/lkml/20220607113238.769088-1-Jason@zx2c4.com/ > > > - Even if very convincing replies can be given to the previous two > > points, wouldn't it be betterr to simply revert the -stable backport > > that introduces the use of the static key, and find a robust and > > portable solution for after v5.19? > > This has already been done: > > [2] https://lore.kernel.org/stable/20220607084005.666059-1-Jason@zx2c4.com/ > > And mentioned here: > > [3] https://lore.kernel.org/lkml/CAHmME9rJif3ydZuFJcSjPxkGMofZkbu2PXcHBF23OWVgGQ4c+A@mail.gmail.com/ > > You're on this thread. > OK, excellent, thanks for confirming. There are so many threads now going on at the same time that I lost track. > > So could we please go back to some basic questions here; > > - Why do we need/want a static key here to begin with? Is is for performance? You still haven't answered this question, f5bda35fba61 only reasons about how we can use a static branch but not why we should. 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 a single conditional branch that will always be predicted correctly at runtime. And it clutters up the code, given that you need to use the execute_in_process_context() helper to perform the static key manipulation outside of the calling context. > > - 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? > But if > the arch solution winds up looking fragile or problematic somehow, then > one of these solutions should do the trick. In particular [1] seems nice > enough that it doesn't really even clutter things up too much as feared. > As I replied there, I think that patch is not as bad as the other ones that have been suggested (including mine). But I still feel we are going through a lot of trouble to enable something that we really don't need here. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel