lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ