Received-SPF: pass (google.com: domain of linux-crypto+bounces-469-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) client-ip=2604:1380:45d1:ec00::1;
Message-ID: <8ddb48606cebe4e404d17a627138aa5c5af6dccd.camel@sipsolutions.net>
Subject: Re: jitterentropy vs. simulation
From: Johannes Berg <johannes@sipsolutions.net>
To: Anton Ivanov <anton.ivanov@kot-begemot.co.uk>, 
	linux-um@lists.infradead.org
Cc: linux-crypto@vger.kernel.org, Stephan =?ISO-8859-1?Q?M=FCller?=
	 <smueller@chronox.de>
Date: Fri, 01 Dec 2023 19:35:11 +0100
In-Reply-To: <7db861e3-60e4-0ed4-9b28-25a89069a9db@kot-begemot.co.uk>
References: 
	<e4800de3138d3987d9f3c68310fcd9f3abc7a366.camel@sipsolutions.net>
	 <7db861e3-60e4-0ed4-9b28-25a89069a9db@kot-begemot.co.uk>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
User-Agent: Evolution 3.48.4 (3.48.4-1.fc38) 
Precedence: bulk
MIME-Version: 1.0

[I guess we should keep the CCs so other see it]

> Looking at the stuck check it will be bogus in simulations.

True.

> You might as well ifdef that instead.
>=20
> If a simulation is running insert the entropy regardless and do not compu=
te the derivatives used in the check.

Actually you mostly don't want anything inserted in that case, so it's
not bad to skip it.

I was mostly thinking this might be better than adding a completely
unrelated ifdef. Also I guess in real systems with a bad implementation
of random_get_entropy(), the second/third derivates might be
constant/zero for quite a while, so may be better to abort?

In any case, I couldn't figure out any way to not configure this into
the kernel when any kind of crypto is also in ...

johannes