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 D92DBC433FE for ; Tue, 1 Nov 2022 13:04:11 +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:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=Nh1g8G8j/FM66mgrW63pagTbmvJUuhxbX1FaaC37LtE=; b=plJxvbCSUgnDyz W6O7gRTmg9Ci5rvA/yAMj5Xr094y708y2gNveswW3unvY3z5kl4xBSFYNFKRgW+fykkIRtp2Z2LFu R0dyyySIBwQFQzFpozHWU8UENosXop1GtHqpwIeDArODPt79aRbbYa7ac7lZnl+qgzLYbc+P+Jer+ EMYk/sT4Wy51qsxv7YLj1yj1FlmOOZUUpWGuaFG7vYSgE11Vphu8DnFW3cftkk2iry+6Ptzjqj9Q/ o93oFmSa7HkLWPlrJAFAa+EfEo8/oYe/kmZ3rDiN7LFMo44x5EcdY3lQqcWphWPl4hEzz1XsH59sL e1fv1nqRFQMbH3o/iDDw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1opqv8-005Cc7-D8; Tue, 01 Nov 2022 13:03:10 +0000 Received: from ams.source.kernel.org ([145.40.68.75]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1opqv4-005CbX-KK for linux-arm-kernel@lists.infradead.org; Tue, 01 Nov 2022 13:03:08 +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 ams.source.kernel.org (Postfix) with ESMTPS id 118CFB81B0D; Tue, 1 Nov 2022 13:03:05 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id BAB39C433D6; Tue, 1 Nov 2022 13:03:02 +0000 (UTC) Authentication-Results: smtp.kernel.org; dkim=pass (1024-bit key) header.d=zx2c4.com header.i=@zx2c4.com header.b="myvlQccd" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zx2c4.com; s=20210105; t=1667307780; 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=aGf3HRCgre3btUoaDn4OQ44V8myJz/3Xau3fRCIpvUk=; b=myvlQccdLLbbOrtow+kUbH/oXOYEc8Oy9LENIq4/ncat6FPoYRAVx9139m1B9/8SVuOXJ1 CIkMB7K2W8O7BGFtcBthO1d7Z+zw2tKWQkTc2ucHEyTq76TFDkgcaYSwkHDXHW/NN0rtmP RBf5hazhmW6EgCY1N4D/nZJ8eKI2Jr0= Received: by mail.zx2c4.com (ZX2C4 Mail Server) with ESMTPSA id 52812150 (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO); Tue, 1 Nov 2022 13:03:00 +0000 (UTC) Date: Tue, 1 Nov 2022 14:02:58 +0100 From: "Jason A. Donenfeld" To: Mark Rutland Cc: Catalin Marinas , linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, Will Deacon , Ard Biesheuvel , Jean-Philippe Brucker Subject: Re: [PATCH v5] random: remove early archrandom abstraction Message-ID: References: <20221101115616.232884-1-Jason@zx2c4.com> <20221101122527.323843-1-Jason@zx2c4.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20221101_060307_132031_AF0724DA X-CRM114-Status: GOOD ( 24.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 Hi Mark, On Tue, Nov 01, 2022 at 12:36:07PM +0000, Mark Rutland wrote: > Hi Jason, > > Sorry for joining this late... > > On Tue, Nov 01, 2022 at 01:25:28PM +0100, Jason A. Donenfeld wrote: > > The arch_get_random*_early() abstraction is not completely useful and > > adds complexity, because it's not a given that there will be no calls to > > arch_get_random*() between random_init_early(), which uses > > arch_get_random*_early(), and init_cpu_features(). During that gap, > > crng_reseed() might be called, which uses arch_get_random*(), since it's > > mostly not init code. > > The original rationale for arch_get_random*_early() was just to seed the RNG > more robustly rather than to feed every possible arch_get_random() call made > early in the boot flow, and the rationale for having a separate functions was > that it was trivial to see by inspection that it was (only) called in the > expected places. > > I'm not wedded to arch_get_random*_early() specifically, but I do think that > having arch_get_random() behave differently depending on which phase of boot > we're in has more scope for error than having a separate call of some sort. > > Other than removing the lines below, what chages is this going to permit? Firstly, the issue with the API is having to remember to use it! There's already been a bug from forgetting to use the _early() call during some refactoring, and I doubt it'll be the last. But also, functions such as crng_reseed()->extract_entropy() wind up being called in both early contexts and normal contexts. It's not feasible to have different paths there, so by having two functions, we miss out on having access during early boot. So I don't want a separate call, both for the API complexity reasons, and because it doesn't really work as intended in the end. Jason _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel