linux-kernel - Re: is "premature next" a real world rng concern, or just an academic exercise?

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]

Message-ID: <5b63a8a37b415db66ffe6b660859e3900c054909.camel@redhat.com>
Date:   Tue, 10 May 2022 17:33:34 -0400
From:   Simo Sorce <simo@...hat.com>
To:     "Jason A. Donenfeld" <Jason@...c4.com>, dodis@...nyu.edu,
        tytso@....edu, nadiah@...ucsd.edu, noahsd@...il.com,
        tessaro@...washington.edu, torvalds@...ux-foundation.org,
        jeanphilippe.aumasson@...il.com, jann@...jh.net,
        keescook@...omium.org, gregkh@...uxfoundation.org,
        peter@...ptojedi.org, linux-crypto@...r.kernel.org,
        linux-kernel@...r.kernel.org, "D. J. Bernstein" <djb@...yp.to>
Subject: Re: is "premature next" a real world rng concern, or just an
 academic exercise?

On Tue, 2022-05-10 at 22:09 +0200, Jason A. Donenfeld wrote:
> For 5.19 (or at this point, more likely 5.20), there's a userspace
> notifier in store, maybe, if I can figure out how to do it right.
> There's a pretty bikesheddy thread here on what shape that interface
> should take: https://lore.kernel.org/lkml/YnA5CUJKvqmXJxf2@zx2c4.com/
> But basically there are some details about how an async interface should
> work, and what the virtual hardware future, if any, looks like for a
> memory mapped race-free polling interface. Plus some considerations on
> how much we should care etc.

Perhaps it might be simpler to add an "epoch" number or similar exposed
via something like a vDSO that proper user space implementations can
then check before returning numbers from PRNGs and will immediately
reseed from /dev/random if it ever changes (rare event).

It is much simpler to poll for this information in user space crypto
libraries than using notifications of any kind given libraries are
generally not in full control of what the process does.

This needs to be polled fast as well, because the whole point of
initializing a PRNG in the library is that asking /dev/urandom all the
time is too slow (due to context switches and syscall overhead), so
anything that would require a context switch in order to pull data from
the PRNG would not really fly.

Note that a generic "epoch" exposed via vDSO would be useful beyond
RNGs, as it would be usable by any other user space that needs to know
that "I have been cloned and I need to do something now" and would be
able to use it immediately w/o the kernel needing to grow any other
specific interface for it.

HTH.
Simo.

-- 
Simo Sorce
RHEL Crypto Team
Red Hat, Inc