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 D4867C43334 for ; Tue, 7 Jun 2022 12:05:17 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S243406AbiFGMFN (ORCPT ); Tue, 7 Jun 2022 08:05:13 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:47648 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S243344AbiFGMFH (ORCPT ); Tue, 7 Jun 2022 08:05:07 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A0B2BF5524 for ; Tue, 7 Jun 2022 05:05:05 -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 3E6D161725 for ; Tue, 7 Jun 2022 12:05:05 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id A6FB0C385A5; Tue, 7 Jun 2022 12:05:03 +0000 (UTC) Authentication-Results: smtp.kernel.org; dkim=pass (1024-bit key) header.d=zx2c4.com header.i=@zx2c4.com header.b="fLCYiTjf" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zx2c4.com; s=20210105; t=1654603502; 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=WX0n+99WwQCrao72endBd42T+qlG0mEcwjlgxCG5GIA=; b=fLCYiTjfT0In+Ev5NqH3le5amnEkT8hfhl+zT2eF1rboaPWVOVKjyJJJFNXGG/oXNGnB8c EhyFl3ugwhPnJMrPnYC2Qqzr4ek5ey84x7iuKQfZm8wgXext+YgTrE5yU5drFXhQogR6nD v/tTdqlpYge3aLZ+JuUeoYsJvzjPafI= Received: by mail.zx2c4.com (ZX2C4 Mail Server) with ESMTPSA id a18ded3b (TLSv1.3:AEAD-AES256-GCM-SHA384:256:NO); Tue, 7 Jun 2022 12:05:01 +0000 (UTC) Date: Tue, 7 Jun 2022 14:04:57 +0200 From: "Jason A. Donenfeld" To: Ard Biesheuvel Cc: linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, Stephen Boyd , Catalin Marinas , Russell King , Arnd Bergmann , Phil Elwell Subject: Re: [PATCH] random: defer use of bootloader randomness to random_init() Message-ID: References: <20220607111514.755009-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 Hi Ard, 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. > 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? > - 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. 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. Jason