[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <YrBT97lARo2QAWVF@zx2c4.com>
Date: Mon, 20 Jun 2022 13:03:19 +0200
From: "Jason A. Donenfeld" <Jason@...c4.com>
To: Harald Freudenberger <freude@...ux.ibm.com>
Cc: linux-s390@...r.kernel.org, linux-kernel@...r.kernel.org,
stable@...r.kernel.org, Ingo Franzki <ifranzki@...ux.ibm.com>,
Juergen Christ <jchrist@...ux.ibm.com>,
Martin Schwidefsky <schwidefsky@...ibm.com>,
Heiko Carstens <heiko.carstens@...ibm.com>
Subject: Re: [PATCH] s390/archrandom: simplify back to earlier design
Hi Harald,
On Mon, Jun 20, 2022 at 12:54:11PM +0200, Harald Freudenberger wrote:
> Hi Jason, I've been on vacation and now seen your s390 arch random
> rework.
> Your assumption is right. The hw TRNG we have on the s390 platform is
> relatively expensive and I had to learn that directly calling the TRNG
> as part of an arch_get_random_{long,int} is not the right way. As we
> also have a NIST 800-90A conform PRNG in hardware, I used it as some
> kind of caching the TRNG random data.
Indeed that's what I saw. I actually think this kind of caching is
undesirable from an rng perspective too, since it essentially means we
have two software rngs, with different lifetimes and semantics on key
duration. So getting rid of that seems like a benefit.
> With all the changes in random.c there is no need to provide any
> arch_get_random_{long,int}() implementation any more.
> However, the arch_get_random_seed functions should provide TRNG
> values to random.c and so I'll have a close look onto your changes.
Right, that's what my patch does.
> Thanks for your patches, I'll come back with some feedback.
Thanks, looking forward. Please be sure to read v3 of the bunch I sent
(rather than this v1 you're replying to here):
https://lore.kernel.org/lkml/20220610222023.378448-1-Jason@zx2c4.com/
Jason
Powered by blists - more mailing lists