From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-yw1-x1135.google.com (mail-yw1-x1135.google.com [IPv6:2607:f8b0:4864:20::1135]) by sourceware.org (Postfix) with ESMTPS id 492703858D37 for ; Mon, 4 Apr 2022 18:23:57 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 492703858D37 Received: by mail-yw1-x1135.google.com with SMTP id 00721157ae682-2db2add4516so110156847b3.1 for ; Mon, 04 Apr 2022 11:23:57 -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=nfBRXdjUMtTpv+JxP4laXlWF5zIhPaQI0fWkzLRVt8Q=; b=RhhdUMhKSHw9VusqumxhnW0j6gfObs7RXAiaFu3M4heQWRVYt7NlWpdRk2DnsUCnkh RkvL+Mcqr+JIz5H1G24SARvoaVTm8PiPmfk6ugj4PnERO+m9RJvR4HZjEk0Fh/VG68oI VM1zQ1mSgDxzE+lbvuUtauFqVFykAOhY7DwR9IDhHX9f6ta3q1mPvta/IYg4P/G71NLY LKD1i+p/ADndrCvs0veLKXvap4PQfXqZmr7jNC9m20+Ikzw5VCl2eglXvDkMEvMliM2v Fw2wITMHO7q28Czt/P8+slfUqVUe38FHZ5ubtf6R556xgRje38NstjTKEHb4CWI3iOG1 ul0Q== X-Gm-Message-State: AOAM532/mOFP8P4BaiNRu7ZtIhW3m2o7og1ikelYvCHG4Tqa0NRzkFt4 AKRO9FDFB6NURvSCDygzRCpjDSeio0yzj+KvmVI= X-Google-Smtp-Source: ABdhPJxqUJOssnvMmjexI4Br5vumPSsGxxdjhWCZy2DHndDmiPoZWhc+X3EA3PfA3R/YdmIyTtnUd13ncywpid1kXSs= X-Received: by 2002:a0d:d98e:0:b0:2e6:1c6d:5300 with SMTP id b136-20020a0dd98e000000b002e61c6d5300mr1240586ywe.427.1649096636391; Mon, 04 Apr 2022 11:23:56 -0700 (PDT) MIME-Version: 1.0 References: <20220328220936.2724834-1-goldstein.w.n@gmail.com> <7b48ece6-392a-0850-c136-01ab751273ef@linaro.org> <72332228-093c-5186-789f-8616cfb93793@linaro.org> <0198ce75-8a8e-4355-eed1-f69dfb6f40f0@linaro.org> <939bcfbb-516e-ab97-f6bf-858c4956c38e@linaro.org> In-Reply-To: <939bcfbb-516e-ab97-f6bf-858c4956c38e@linaro.org> From: Noah Goldstein Date: Mon, 4 Apr 2022 13:23:45 -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.2 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:23:59 -0000 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 secur= ity > >> 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. 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? > > [1] https://www.youtube.com/watch?v=3Dgp_90-3R0pE