From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oa1-x32.google.com (mail-oa1-x32.google.com [IPv6:2001:4860:4864:20::32]) by sourceware.org (Postfix) with ESMTPS id A09D73858D37 for ; Mon, 4 Apr 2022 19:20:33 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org A09D73858D37 Received: by mail-oa1-x32.google.com with SMTP id 586e51a60fabf-dacc470e03so11885585fac.5 for ; Mon, 04 Apr 2022 12:20:33 -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=OxssRFcY8GiDDX3X/+bmOlrMQGWhLCQ7/Y5vTINm5pk=; b=pDJ5h5lbOzIuEU449LCeRFPVacEqPh17lSICPewv4iv/crIKPLjSjro8UqQA8B0Tk1 1aPahbli6tor5AVBPm3Iit6/KrC9mgKjYjSNOopA8jSrDQdk2pirf8VYSoxQnfSCpBxA xmHOsK8Af1zYqmcBiHrgtu4JwrxLGysvxQgGqxeTzpuUu4ldtY73S9E5JYazyGznV0M0 utgX6VQA8aGQN8ZkEBVxW/J7tovAuIISCX8XJhDA7RI8vIPFczRnmg1ODilm0K1Z6bnB O7x58lWzzyNEN5b9vy1wwrv5kc5KFyyMtMhTVuPfWAHfUr0CCNhZCmVF8wBcsRq2EXrI KWIg== X-Gm-Message-State: AOAM531y65EoXzSONBjWzA5C3ZDW003Eu0vB5ohsM2kTCmxQtvA2/kN5 PKA6MtjqswR8VPqUZaIdSekYeezBgZ4OXg== X-Google-Smtp-Source: ABdhPJwxXGYVFszYgDGnJAEBuQ3B4Q1wfjFim9L+vjmajjlZ/tseWIIWHOEkAs+8o/mRonHNQsxLpQ== X-Received: by 2002:a05:6870:2198:b0:e2:583:ddc6 with SMTP id l24-20020a056870219800b000e20583ddc6mr397511oae.29.1649100032808; Mon, 04 Apr 2022 12:20:32 -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 r29-20020a056808211d00b002f76ea70064sm4448730oiw.35.2022.04.04.12.20.30 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 04 Apr 2022 12:20:32 -0700 (PDT) Message-ID: <2c5d7c2d-7be4-c968-31b3-46231dc60e34@linaro.org> Date: Mon, 4 Apr 2022 16:20:29 -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> 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:20:35 -0000 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).