From: Simo Sorce <simo@redhat.com>
To: Johannes Berg <johannes@sipsolutions.net>,
Anton Ivanov <anton.ivanov@kot-begemot.co.uk>,
linux-um@lists.infradead.org
Cc: linux-crypto@vger.kernel.org, "Stephan Müller" <smueller@chronox.de>
Subject: Re: jitterentropy vs. simulation
Date: Fri, 01 Dec 2023 14:25:37 -0500 [thread overview]
Message-ID: <e1b3ccb744d67e6214cf206ba8480cb3e35694cf.camel@redhat.com> (raw)
In-Reply-To: <8ddb48606cebe4e404d17a627138aa5c5af6dccd.camel@sipsolutions.net>
On Fri, 2023-12-01 at 19:35 +0100, Johannes Berg wrote:
> [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.
> >
> > If a simulation is running insert the entropy regardless and do not compute 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 ...
Doesn't this imply the simulation is not complete and you need to add
clock jitter for the simulation to be more useful?
You can use the host rng to add random jitter to the simulation clock.
Simo.
--
Simo Sorce,
DE @ RHEL Crypto Team,
Red Hat, Inc
next prev parent reply other threads:[~2023-12-01 19:28 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-12-01 10:21 jitterentropy vs. simulation Johannes Berg
2023-12-01 18:03 ` Anton Ivanov
2023-12-01 18:35 ` Johannes Berg
2023-12-01 19:25 ` Simo Sorce [this message]
2023-12-01 20:04 ` Johannes Berg
2023-12-04 8:52 ` Stephan Mueller
2023-12-04 10:24 ` Johannes Berg
2023-12-04 10:35 ` Stephan Mueller
2023-12-04 12:06 ` Benjamin Beichler
2023-12-04 12:50 ` Anton Ivanov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=e1b3ccb744d67e6214cf206ba8480cb3e35694cf.camel@redhat.com \
--to=simo@redhat.com \
--cc=anton.ivanov@kot-begemot.co.uk \
--cc=johannes@sipsolutions.net \
--cc=linux-crypto@vger.kernel.org \
--cc=linux-um@lists.infradead.org \
--cc=smueller@chronox.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox