Received-SPF: pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Sun, 24 Jul 2022 00:59:37 +0200
From:   "Jason A. Donenfeld" <Jason@zx2c4.com>
To:     Cristian =?utf-8?Q?Rodr=C3=ADguez?= <crrodriguez@opensuse.org>
Cc:     libc-alpha@sourceware.org,
        Adhemerval Zanella Netto <adhemerval.zanella@linaro.org>,
        Florian Weimer <fweimer@redhat.com>,
        Yann Droneaud <ydroneaud@opteya.com>, jann@thejh.net,
        Michael@phoronix.com, linux-crypto@vger.kernel.org
Subject: Re: arc4random - are you sure we want these?
Message-ID: <Ytx9WW4Z90lx8MQt@zx2c4.com>
References: <YtwgTySJyky0OcgG@zx2c4.com>
 <Ytwg8YEJn+76h5g9@zx2c4.com>
 <CAPBLoAdtEcpJg7sZQ7+z7HeCQzAs7Am7ep9GBFuBGxUeC3NyEw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <CAPBLoAdtEcpJg7sZQ7+z7HeCQzAs7Am7ep9GBFuBGxUeC3NyEw@mail.gmail.com>
Precedence: bulk

Hi Cristian,

On Sat, Jul 23, 2022 at 03:04:36PM -0400, Cristian Rodríguez wrote:
> On linux just making this interface call "something" from the VDSO that
> 
> - does not block.
> - cannot ever fail or if it does indeed need to bail out it kills the
> calling thread as last resort.
> 
> (if neither of those can be provided, we are back to square one)
> 
> Will be beyond awesome because it could be usable everywhere,
> including the dynamic linker, malloc or whatever else
> question is..is there any at least experimental patch  with a hope of
> beign accepted available ?

Doesn't getrandom() already basically have this quality? If you call
getrandom(0), it'll block until the RNG is initialized once (which now
happens pretty reliably early on in boot). If you call getrandom(GRND_
INSECURE), it will skip that blocking. Both mechanisms are reliable and
available on all current kernel.org stable kernels.

Is there something about these you don't like and think need fixing? I'm
open to suggestions on how to further improve that interface if it has a
notable shortcoming.

If somebody has a compelling performance case that's widespread and
can't be fixed in the kernel alone, I wouldn't be adverse to vDSOing it.
But such an undertaking would probably be contingent on doing this with
the glibc developers, rather than trying to retroactively bandaid an
addition that shipped broken with a documentation cop-out.

Jason