From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-yb1-xb33.google.com (mail-yb1-xb33.google.com [IPv6:2607:f8b0:4864:20::b33]) by sourceware.org (Postfix) with ESMTPS id 2F2353858D37 for ; Mon, 4 Apr 2022 18:52:17 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 2F2353858D37 Received: by mail-yb1-xb33.google.com with SMTP id x21so13135955ybd.6 for ; Mon, 04 Apr 2022 11:52:17 -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=fUrqyRFpURlBP7rdXHtljnRWPhJ4j8ziVQJGogR7EeQ=; b=fcE0XEhasHCPdHbUE7Z/nD6UjTOn/AzLdYli+bK2P6toIV/xvVWIybZkVs9LguyHeo LKMihSHIXw9ztjKCVOtnMPyZNSvJfFitLDh7tyyHIRr3kumyrDytapE195KQ3eNQv8jM odkknDl/Tht1cgnldqz60HVOTSzcW1HfV9bzu5U8VHYIVRNeqzfaHAFsd7GEuiebU21h 5VhHKtTG2ER6NFZyYqyksRdQoTvfjMHQxO/KHaIYzptChbo6BW2MS3Gp1IzkOfCtk5uV PSAPf/20zCMbLWc+wugR4TwDJDkMSwEJNkTunF2sOlrlZb/yL4F1u/jOS20QChoJRgVI cpcw== X-Gm-Message-State: AOAM533Awb6MSO8CN0gEg/W/5+dMzuqDcLvC5AcDJcGfhHFoLoYFwXRv 5HBRLL5A+L62+ZnjF5G+w6QOpHXwvBJb/yoFkYg= X-Google-Smtp-Source: ABdhPJzr2GhijPLjwbsWnumt33r/Q+6COELzSm1gFV7gAFKufXlO31wSLu9M2WlBekvRYEzACN3vqrp6UWerFrQWgI4= X-Received: by 2002:a25:824b:0:b0:635:2f1:c146 with SMTP id d11-20020a25824b000000b0063502f1c146mr1021317ybn.143.1649098336675; Mon, 04 Apr 2022 11:52:16 -0700 (PDT) MIME-Version: 1.0 References: <20220328220936.2724834-1-goldstein.w.n@gmail.com> <72332228-093c-5186-789f-8616cfb93793@linaro.org> <0198ce75-8a8e-4355-eed1-f69dfb6f40f0@linaro.org> <939bcfbb-516e-ab97-f6bf-858c4956c38e@linaro.org> <29605c5e-de43-3370-3cee-9d7608cb753f@linaro.org> In-Reply-To: <29605c5e-de43-3370-3cee-9d7608cb753f@linaro.org> From: Noah Goldstein Date: Mon, 4 Apr 2022 13:52:05 -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=-2.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 18:52:18 -0000 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 sec= urity > >>>> 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 to > >> come up with a internal PRNG interface that can be used internally an= d > >> 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 i= f > >> we find out that it does not fit. The main issue is to glue together > >> all the requirements to have a concise internal interface, taking in > >> consideration the glibc constrains to work with multiple kernel versio= n > >> and environments (where we can't assume we have access to a source or > >> 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 would > prefer to incremental add per-thread optimization than dump a large patch > so we can review in integrate the code more easier. > > > > > > > Regarding this patch, do we want to skip it and just wait on arc4random > > interface in kernel/glibc or should I go forward with it and some arch > > 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 lightweight 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 vds= o gettime. But agree the improvement gains a minimal so if people don't feel its worth the added complexity we can wait on a strong arch-random interface. > > > > >> > >> [1] https://www.youtube.com/watch?v=3Dgp_90-3R0pE