From: "Jason A. Donenfeld" <Jason@zx2c4.com>
To: Holger Dengler <dengler@linux.ibm.com>
Cc: Harald Freudenberger <freude@linux.ibm.com>,
Heiko Carstens <hca@linux.ibm.com>,
Vasily Gorbik <gor@linux.ibm.com>,
Alexander Gordeev <agordeev@linux.ibm.com>,
Christian Borntraeger <borntraeger@linux.ibm.com>,
Juergen Christ <jchrist@linux.ibm.com>,
linux-crypto@vger.kernel.org, linux-s390@vger.kernel.org
Subject: Re: [PATCH v1 1/1] s390/arch_random: Buffer true random data
Date: Tue, 5 Jul 2022 20:19:11 +0200 [thread overview]
Message-ID: <YsSAn2qXqlFkS5sH@zx2c4.com> (raw)
In-Reply-To: <30e681b2-a411-cdb1-4b46-243db25abeef@linux.ibm.com>
Hey Holger,
On Tue, Jul 05, 2022 at 07:47:37PM +0200, Holger Dengler wrote:
> A trng call runs for minimal ~20-190us for 32 bytes. 20us on newer
> machine generations, 190us on older ones. These are not 100% exact
> measurements, but the dimension should be correct.
Holy smokes. Yea, okay, I see what you're saying. So indeed it sounds
like the `!in_hardirq()` addition would be a good idea. Let's do that.
Also, I noticed that the TRNG has a hwrng driver. That means the RNG
will still be getting continuous input from it in a kthread, not an
interrupt handler, so from a crypto PoV, we're not really losing /that/
much by adding the `!in_hardirq()` clause. So all and all, that seems
like the simplest solution without too big of a downside.
Jason
next prev parent reply other threads:[~2022-07-05 18:19 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-07-05 11:27 [PATCH v1 0/1] s390/archrandom: use buffered random data Holger Dengler
2022-07-05 11:27 ` [PATCH v1 1/1] s390/arch_random: Buffer true " Holger Dengler
2022-07-05 13:18 ` Jason A. Donenfeld
2022-07-05 13:42 ` Jason A. Donenfeld
2022-07-05 14:58 ` Holger Dengler
2022-07-05 15:11 ` Jason A. Donenfeld
2022-07-05 16:27 ` Holger Dengler
2022-07-05 16:35 ` Jason A. Donenfeld
2022-07-05 17:47 ` Holger Dengler
2022-07-05 18:19 ` Jason A. Donenfeld [this message]
2022-07-05 19:28 ` Holger Dengler
2022-07-06 16:18 ` Harald Freudenberger
2022-07-06 16:26 ` Jason A. Donenfeld
2022-07-06 18:29 ` Christian Borntraeger
2022-07-06 22:34 ` Jason A. Donenfeld
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=YsSAn2qXqlFkS5sH@zx2c4.com \
--to=jason@zx2c4.com \
--cc=agordeev@linux.ibm.com \
--cc=borntraeger@linux.ibm.com \
--cc=dengler@linux.ibm.com \
--cc=freude@linux.ibm.com \
--cc=gor@linux.ibm.com \
--cc=hca@linux.ibm.com \
--cc=jchrist@linux.ibm.com \
--cc=linux-crypto@vger.kernel.org \
--cc=linux-s390@vger.kernel.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.