From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id D40DB13CFA3; Thu, 23 May 2024 09:53:10 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1716457991; cv=none; b=UZVhxjpKLYHjX2osFgCMxTYTLf1xAKApE8ZypOp+fCNk37akBASRA2rJ85Rbl5/7+vi+WvP2+VJJceJtrVElf55j7kOqDHUvoHd+EIOZWC/f4WZqgbaIQBMykd2vuyjrsd5iji+2cdkKnS9eW2xGFw1PpL6e0xnSdNfi473a8JI= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1716457991; c=relaxed/simple; bh=Z+LJ9o02AKGYyJoKzdsD0Mhmkl4h3nuqGk+uSvDjGlk=; h=Mime-Version:Content-Type:Date:Message-Id:Cc:Subject:From:To: References:In-Reply-To; b=rVBpl4FAJeOYN6oYL05NnUuxtOoxswX4+A8n53QEZd3lS2l1q3I/httBtAQukd+u48erl1wAll4+BUVv6+A6wDfiVPei55nvVBumPKCsrEk/teQU4fnizTJIzyBwsEQrgBF7K0nxjFlcvkU9JPsbDPoq7eVw9ZEYz7hGt0KGPdA= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=F/7IpU9F; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="F/7IpU9F" Received: by smtp.kernel.org (Postfix) with ESMTPSA id AACC8C2BD10; Thu, 23 May 2024 09:53:06 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1716457990; bh=Z+LJ9o02AKGYyJoKzdsD0Mhmkl4h3nuqGk+uSvDjGlk=; h=Date:Cc:Subject:From:To:References:In-Reply-To:From; b=F/7IpU9FUZAvpfEh0/t33PXl93JMwcJoeQ2AOMEWlwTURqgD5s5bE3ddLqt61tRFD 55A0EWMe86CTIkwwDgMd3s6pX9f3Lahh65Z1XyTNtHkoRM1v8yzOftjrp3/vkcZ01t FVvX6NIP/+def5o2ISG4QbnYYy3+azOnfJzI7Gc5nMwGjd2dY0xjfGCtyNv1EdQjeI vmY3X9TG06PKNJL8VJDTYu3dHd6gSZOK1ezA9ifCiTBRA6hIB+zjApAbJZPH9f6Fn6 /TgWTUlwBBvcifgx8kUQ2lRqfG73fQ8aGiDj7F8F72D6eZo+E8TEiQYaqjmkorNPwu tDh7gMHJEz3UQ== Precedence: bulk X-Mailing-List: linux-integrity@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 Date: Thu, 23 May 2024 12:53:04 +0300 Message-Id: Cc: =?utf-8?b?TsOtY29sYXMgRi4gUi4gQS4gUHJhZG8=?= , "Eric Biggers" , "James Bottomley" , "Ard Biesheuvel" , "Linux Crypto Mailing List" , , , , , "Tejun Heo" , "Linux Kernel Mailing List" , "Kees Cook" , "Torsten Duwe" , "H. Peter Anvin" , "Theodore Ts'o" , "Jason A. Donenfeld" Subject: Re: [v3 PATCH] hwrng: core - Remove add_early_randomness From: "Jarkko Sakkinen" To: "Herbert Xu" , "Linus Torvalds" X-Mailer: aerc 0.17.0 References: <66ec985f3ee229135bf748f1b0874d5367a74d7f.camel@HansenPartnership.com> <20240518043115.GA53815@sol.localdomain> <00bcfa65-384d-46ae-ab8b-30f12487928b@notapiano> <07512097-8198-4a84-b166-ef9809c2913b@notapiano> In-Reply-To: On Thu May 23, 2024 at 7:49 AM EEST, Herbert Xu wrote: > On Wed, May 22, 2024 at 03:53:23PM -0700, Linus Torvalds wrote: > >=20 > > That said, looking at the code in question, there are other oddities > > going on. Even the "we found a favorite new rng" case looks rather > > strange. The thread we use - nice and asynchronous - seems to sleep > > only if the randomness source is emptied. > >=20 > > What if you have a really good source of hw randomness? That looks > > like a busy loop to me, but hopefully I'm missing something obvious. > > Yes that does look strange. So I dug up the original patch at > > https://lore.kernel.org/all/20140317165012.GC1763@lst.de/ > > and therein lies the answer. It's relying on random.c to push back > when the amount of new entropy exceeds what it needs. IOW we will > sleep via add_hwgenerator_randomness when random.c decides that > enough is enough. In fact the rate is much less now compared to > when the patch was first applied. Just throwing something because came to mind, not a serious suggestion. In crypto_larval_lookup I see statements like this: request_module("crypto-%s", name); You could potentially bake up a section/table to vmlinux which would have entries like: "module name", 1/0 '1' would mean built-in. Then for early randomness use only stuff that is built-in. Came to mind from arch/x86/realmode for which I baked in a table for relocation (this was a collaborative work with H. Peter Anvin in 2012 to make trampoline code relocatable but is still a legit example to do such shenanigans in a subystem). BR, Jarkko