From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oo1-xc2e.google.com (mail-oo1-xc2e.google.com [IPv6:2607:f8b0:4864:20::c2e]) by sourceware.org (Postfix) with ESMTPS id 1BCD33857434 for ; Mon, 4 Apr 2022 19:57:50 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 1BCD33857434 Received: by mail-oo1-xc2e.google.com with SMTP id u30-20020a4a6c5e000000b00320d8dc2438so1925122oof.12 for ; Mon, 04 Apr 2022 12:57:50 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:cc:references:from:in-reply-to :content-transfer-encoding; bh=CP5m6oWnI6d+7bG7Szd8+ASI9YX3sSg9FAfx9C5c8I0=; b=IvA2yCopC7QOdWjxceEjbmPoRXx+uXlczhCb9/wqELO1+yq3fzlMA5ML5rqt2TLQUM vrW5nPrkQ98VXjuVS51ztn6aL+98LYWBM7uwVUoJfe8WswnVJEiiFbZ5lIID5mrPV4Vo 4FZjhD3cLVAghqQM5jatfqpjl98+Oezpg/Jr7TQ0mBkgrqthF/Nd92DgcEQ6qfct3Kow rw+SQoIfid7n2EhGqXE7gTrmFJvVcXHHXkahxDlXClQTgVM5QIcmQGIWNthowN0HeKZZ I0TsxquowPA3dSNWVfBJBwxxO9Hwh1zskElgdBw3EGIdlmfna+jEg60GSCHl8gmjtBaK 5cWg== X-Gm-Message-State: AOAM531mRXnOQknkpj4i/OxXbkjoS2Nz/GKoe6Z5gjPF03tpWkNbHsMq w1HodQdV55pxQrPJz2XeBRrfgA== X-Google-Smtp-Source: ABdhPJzV+TmuQkj5byADxilspLvgs+p7svp4xlYsvVmEcsBNogm2XNaKjSif4O+pHf9LdAkxwHcVeg== X-Received: by 2002:a4a:5510:0:b0:328:faf7:9ed9 with SMTP id e16-20020a4a5510000000b00328faf79ed9mr417342oob.65.1649102269329; Mon, 04 Apr 2022 12:57:49 -0700 (PDT) Received: from ?IPV6:2804:431:c7cb:a6c0:94cf:60bc:16d1:2727? ([2804:431:c7cb:a6c0:94cf:60bc:16d1:2727]) by smtp.gmail.com with ESMTPSA id p14-20020a9d744e000000b005b235f5cf92sm4928148otk.65.2022.04.04.12.57.45 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 04 Apr 2022 12:57:48 -0700 (PDT) Message-ID: <7fdb5ea5-9929-7d55-6b36-960268a4c440@linaro.org> Date: Mon, 4 Apr 2022 16:57:44 -0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.8.0 Subject: Re: [PATCH v1 1/2] random-bits: Factor out entropy generating function Content-Language: en-US To: Noah Goldstein Cc: =?UTF-8?Q?Cristian_Rodr=c3=adguez?= , "Jason A. Donenfeld" , GNU C Library , Florian Weimer 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> From: Adhemerval Zanella In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-6.7 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, NICE_REPLY_A, 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:57:51 -0000 On 04/04/2022 16:48, Noah Goldstein wrote: > 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íguez 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 security >>>>>>>> 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 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 together >>>>>> all the requirements to have a concise internal interface, taking in >>>>>> consideration the glibc constrains to work with multiple kernel version >>>>>> 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 vdso >>> 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. >> >> I think for mutex optimization it would be better to just add a arch-specific >> jitter code and use the backoff optimization iff the arch-specific code is >> used. And maybe not tied to random_bits(), since I am not sure if an interface >> like arc4random would be good to use in such scenario (since a possible state >> 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'? Yeah, this would be better than try to improve random_bits. Also, recently we are trying to avoid internal HAS/HAVE defines, it is better to add a generic interface that does either nothing or return a default value (so default get_fast_jitter() would return 1 or 0, so the mutex code will se it just do the current spinning without backoff).