From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-yw1-x112d.google.com (mail-yw1-x112d.google.com [IPv6:2607:f8b0:4864:20::112d]) by sourceware.org (Postfix) with ESMTPS id A60F73850845 for ; Wed, 29 Jun 2022 22:05:24 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org A60F73850845 Received: by mail-yw1-x112d.google.com with SMTP id 00721157ae682-31780ad7535so161834327b3.8 for ; Wed, 29 Jun 2022 15:05:24 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=S4ZhMok+tl4rC03qGc2VW6Qs2Qnd50R13GkFHAADwmU=; b=Ccm1ZZnrvtmFvyY4G3M2yUuUBgdvOSqqleaYWirCH+ROQQoXGLEp88uV0/KUaovX2r Y0O+5pdCRdcf/mplnFkFgvFy8CN3JgjwJbvoRXOmqMh5BCZju8r0HIVCem12WnP33PMI 0RyncX9Ko7yDdWAoIn3thDuDMqPjLqjkqiU5mGzYUHHlJBwtbGIiPr0a9cMmsYRu1UH0 hzvJIgrmOXUxrgNC4nhcjIF51N77iXQoOjiUfg3n97mDfyEn/RQtpQ7gAZWo+EEo4z1I v9dDwqnITb7WPykbV67HXFZ/2YayduXFLvqsCwLemte5fqro6aaMqhldkX7c7UsGbqyW SKJw== X-Gm-Message-State: AJIora9hwnMTAtsbCVQalg/3oFJljEael5xS1xZwlXyhzDztFXr0daWh A5gpGiWs/PBqGWay/V8WHNdoVCC2aRQ0q01uEjY= X-Google-Smtp-Source: AGRyM1tQ0AVWSC5LVYO8xm/nMsY9HoXkkdk3455hVw/hMJPnxYf3HQqwcH+RAwEXMlsL2ldt496w0c1LPfkLwq3IvVM= X-Received: by 2002:a0d:cc91:0:b0:317:f785:5418 with SMTP id o139-20020a0dcc91000000b00317f7855418mr6490031ywd.34.1656540324070; Wed, 29 Jun 2022 15:05:24 -0700 (PDT) MIME-Version: 1.0 References: <20220629213428.3065430-1-adhemerval.zanella@linaro.org> <20220629213428.3065430-10-adhemerval.zanella@linaro.org> <1471BD6A-8680-41E9-9FE5-B1DC45940264@linaro.org> In-Reply-To: <1471BD6A-8680-41E9-9FE5-B1DC45940264@linaro.org> From: Noah Goldstein Date: Wed, 29 Jun 2022 15:05:13 -0700 Message-ID: Subject: Re: [PATCH v8 9/9] manual: Add documentation for arc4random functions To: Adhemerval Zanella Cc: GNU C Library , Florian Weimer Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-8.3 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, GIT_PATCH_0, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jun 2022 22:05:26 -0000 On Wed, Jun 29, 2022 at 2:53 PM Adhemerval Zanella wrote: > > > > > On 29 Jun 2022, at 18:45, Noah Goldstein wrote: > > > > On Wed, Jun 29, 2022 at 2:36 PM Adhemerval Zanella via Libc-alpha > > wrote: > >> > >> --- > >> manual/math.texi | 45 +++++++++++++++++++++++++++++++++++++++++++++ > >> 1 file changed, 45 insertions(+) > >> > >> diff --git a/manual/math.texi b/manual/math.texi > >> index 477a18b6d1..ab96726e57 100644 > >> --- a/manual/math.texi > >> +++ b/manual/math.texi > >> @@ -1447,6 +1447,7 @@ systems. > >> * ISO Random:: @code{rand} and friends. > >> * BSD Random:: @code{random} and friends. > >> * SVID Random:: @code{drand48} and friends. > >> +* High Quality Random:: @code{arc4random} and friends. > >> @end menu > >> > >> @node ISO Random > >> @@ -1985,6 +1986,50 @@ This function is a GNU extension and should not be used in portable > >> programs. > >> @end deftypefun > >> > >> +@node High Quality Random > >> +@subsection High Quality Random Number Functions > >> + > >> +This section describes the random number functions provided as a GNU > >> +extension, based on OpenBSD interfaces. > >> + > >> +@Theglibc{} uses kernel entropy obtained either through @code{getrandom} > >> +or by reading @file{/dev/urandom} to seed and periodically re-seed the > >> +internal state. A per-thread data pool is used, which allows fast output > >> +generation. > >> + > > > > Are we committing to per-thread data pools? I thought there were ideas to > > use rseq. > > For this version yes, since it works on all supported kernels (even for the > ones without getentropy support) and on all architectures. I do not know how > feasible it would be to implement per-cpu caches along with rseq and it would > require a fallback for older kernel (most likely a per-thread cache as this > version), although it might be future improvement. I guess do we want to explicitly say per-thread buffer if we may want to experiment with something else? Just seems like the kind of thing that might make it impossible to re-implement another way. What about something like: "The data-pool is implemented to minimize cross-core contention allowing fast output generation"?