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;
MIME-Version: 1.0
References: <YtwgTySJyky0OcgG@zx2c4.com> <Ytwg8YEJn+76h5g9@zx2c4.com>
 <87bktdsdrk.fsf@oldenburg.str.redhat.com> <Yt54x7uWnsL3eZSx@zx2c4.com>
 <87v8rlqscj.fsf@oldenburg.str.redhat.com> <Yt6eHfnlEN8ViWrA@zx2c4.com>
In-Reply-To: <Yt6eHfnlEN8ViWrA@zx2c4.com>
From:   =?UTF-8?Q?Cristian_Rodr=C3=ADguez?= <crrodriguez@opensuse.org>
Date:   Mon, 25 Jul 2022 09:58:23 -0400
Message-ID: <CAPBLoAcadZw=bqKRn1Wd+NU=Cp+M+4ASB1e4qZbi01vZsgSsNw@mail.gmail.com>
Subject: Re: arc4random - are you sure we want these?
To:     "Jason A. Donenfeld" <Jason@zx2c4.com>
Cc:     Florian Weimer <fweimer@redhat.com>,
        Yann Droneaud <ydroneaud@opteya.com>, jann@thejh.net,
        "Jason A. Donenfeld via Libc-alpha" <libc-alpha@sourceware.org>,
        linux-crypto@vger.kernel.org, Michael@phoronix.com
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

On Mon, Jul 25, 2022 at 9:44 AM Jason A. Donenfeld via Libc-alpha
<libc-alpha@sourceware.org> wrote:

> Or, if you insist on providing these functions t o d a y, and won't heed
> my warnings about designing the APIs alongside the implementations, then
> just make them thin wrappers over getrandom(0) *without* doing fancy
> buffering, and then optimizations later can improve it. That would be
> the incremental approach, which wouldn't harm potential users. It also
> wouldn't shut the door on doing the buffering: if the kernel
> optimization improvements go nowhere, and you decide it's a lost cause,
> you can always change the way it works later, and make that decision
> then.

My 2CLP here if that matters..I agree with this sentiment/approach.
provide this functions for source compat which all juist call
getrandom and abort on failure *for now*
and then  a future iteration can have something done about the syscall
overhead with kernel help.