From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-yw1-x1132.google.com (mail-yw1-x1132.google.com [IPv6:2607:f8b0:4864:20::1132]) by sourceware.org (Postfix) with ESMTPS id 8C0A93858C52 for ; Mon, 4 Apr 2022 19:48:18 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 8C0A93858C52 Received: by mail-yw1-x1132.google.com with SMTP id 00721157ae682-2e68c95e0f9so113172797b3.0 for ; Mon, 04 Apr 2022 12:48:18 -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:content-transfer-encoding; bh=5c5Txw/PXvB8J078RD9icjHYlmY93LKHf1qZaqtixNQ=; b=YqpR2NnS6VTMlAfu75RAuEtV2u0QLir0dlI34p3jRLp5YEm73pHP6NWnlfjUpywVGF bb/zcD6oKV7KC/LFqiuxE6VNukMXbeQ8WeziJ3v4AvFb4kiqZ+uiUVE+WcAJW9UEOHqO Ka7h/pSljq+NcN6aBIGI6QzzSrv7GySjEZYRcRBf0cLF8sX3mNyqNc5AnHUPwRNUgAuG ac/uywYOYD6Cpvs4a8Resj16y8O0YTp88I1lNYPl61T4nnMAGYknqCBkvdQRXF3lscQ7 BzLiZm+q/4BoQ0LFugZJ60CEFtiP6F0gODGIfoG2Dfu5f4hpWE6a/4FrMDVIyUvM8fff tC1g== X-Gm-Message-State: AOAM533rimma85QzxO+g64+Ha/zWGNkE3/6YwhQCqRuuAULafpDC9J+m mozJ6q6PzjB5FbNf1WFSoJYFfGHjh7rv0sWyjUY= X-Google-Smtp-Source: ABdhPJyLF1fHdu2XNZTdiGSUisopkiXgpYnZ6y2MKC69P5qhhNIaD0qC/pkvbr6/o2x9jdHERuoEof8VUp8oXLhHdM4= X-Received: by 2002:a81:1cc6:0:b0:2d5:427c:a23e with SMTP id c189-20020a811cc6000000b002d5427ca23emr1491595ywc.496.1649101697782; Mon, 04 Apr 2022 12:48:17 -0700 (PDT) MIME-Version: 1.0 References: <20220328220936.2724834-1-goldstein.w.n@gmail.com> <0198ce75-8a8e-4355-eed1-f69dfb6f40f0@linaro.org> <939bcfbb-516e-ab97-f6bf-858c4956c38e@linaro.org> <29605c5e-de43-3370-3cee-9d7608cb753f@linaro.org> <2c5d7c2d-7be4-c968-31b3-46231dc60e34@linaro.org> In-Reply-To: <2c5d7c2d-7be4-c968-31b3-46231dc60e34@linaro.org> From: Noah Goldstein Date: Mon, 4 Apr 2022 14:48:07 -0500 Message-ID: Subject: Re: [PATCH v1 1/2] random-bits: Factor out entropy generating function To: Adhemerval Zanella Cc: =?UTF-8?Q?Cristian_Rodr=C3=ADguez?= , "Jason A. Donenfeld" , GNU C Library , Florian Weimer Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-3.3 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) 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: Mon, 04 Apr 2022 19:48:20 -0000 On Mon, Apr 4, 2022 at 2:20 PM Adhemerval Zanella wrote: > > > > On 04/04/2022 15:52, Noah Goldstein wrote: > > On Mon, Apr 4, 2022 at 1:38 PM Adhemerval Zanella > > wrote: > >> > >> > >> > >> On 04/04/2022 15:23, Noah Goldstein wrote: > >>> On Mon, Apr 4, 2022 at 12:42 PM Adhemerval Zanella > >>> wrote: > >>>> > >>>> > >>>> > >>>> On 01/04/2022 15:01, Cristian Rodr=C3=ADguez wrote: > >>>>> On Thu, Mar 31, 2022 at 8:05 PM Noah Goldstein wrote: > >>>>> > >>>>>> AFAIK our goal is entropy more so than security. For example > >>>>>> if this is used to generate jiffies to stagger threads its not a s= ecurity > >>>>>> issue in any sense, it's just not ideal for performance. > >>>>> > >>>>> In any case this should be more than fast enough for the other use > >>>>> cases of random_bits() .. maybe one new random_bits_fast() function > >>>>> foe edge cases where even this is too slow? > >>>> > >>>> I think we are bike-shedding in the same issue OpenBSD guys stumbled > >>>> and which they have solved 10 years ago [1]. Essentially, we need t= o > >>>> come up with a internal PRNG interface that can be used internally = and > >>>> externally, instead of reinventing cleaver ways to use the timer as > >>>> entropy source. > >>>> > >>>> The issue is not really the cypher used, ideally it could be replace= if > >>>> we find out that it does not fit. The main issue is to glue togethe= r > >>>> all the requirements to have a concise internal interface, taking in > >>>> consideration the glibc constrains to work with multiple kernel vers= ion > >>>> and environments (where we can't assume we have access to a source o= r > >>>> reliable entropy like getrandom syscall). > >>>> > >>>> My plan to rehearse Florian arc4random proposal to have some simpler > >>>> to where we might improve upon (a simpler fork detection for kernels > >>>> without MADV_WIPEONFORK that just issue a atfork handle, maybe using > >>>> ChaCha20 as virtually all other systems do, no per-thread state). > >>> > >>> Why no per-thread / per-cpu? It seems otherwise there will need to be > >>> some explicit synchronization on the stream. > >> > >> Mainly because it simplifies a lot the *initial* implementation. I wou= ld > >> prefer to incremental add per-thread optimization than dump a large pa= tch > >> so we can review in integrate the code more easier. > >> > >>> > >>> > >>> Regarding this patch, do we want to skip it and just wait on arc4rand= om > >>> interface in kernel/glibc or should I go forward with it and some arc= h > >>> specific entropy functions in the mean-time? > >> > >> I don't have a strong opinion on this patch, it does improve x86_64 > >> latency on random_bits although currently internal usage are far from > >> latency sensitive. It is really a microoptimization without much real > >> work gain for current code. > > > > That's fair. The motivation is so random_bits can be used for lightweig= ht > > jitter i.e in cases like: > > > > [v2] nptl: Add backoff mechanism to spinlock loop > > > > The x86 backend with `rdtsc` is just because it's a simple improvement, > > other arch will hopefully be able to get off syscall if they don't have= vdso > > gettime. > > But agree the improvement gains a minimal so if people don't feel its w= orth > > the added complexity we can wait on a strong arch-random interface. > > I think for mutex optimization it would be better to just add a arch-spec= ific > jitter code and use the backoff optimization iff the arch-specific code i= s > used. And maybe not tied to random_bits(), since I am not sure if an inte= rface > like arc4random would be good to use in such scenario (since a possible s= tate > reschedule might call getentropy with my add unexpected latency). So you propose drop this patch in favor of some new internal interface like get_fast_jitter() and a define such as 'HAS_FAST_JITTER'?