From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oi1-x22d.google.com (mail-oi1-x22d.google.com [IPv6:2607:f8b0:4864:20::22d]) by sourceware.org (Postfix) with ESMTPS id 6B8DA3858C52 for ; Mon, 4 Apr 2022 18:38:44 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 6B8DA3858C52 Received: by mail-oi1-x22d.google.com with SMTP id t21so10964769oie.11 for ; Mon, 04 Apr 2022 11:38:44 -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=z8BTz7tkaeXSQkr9M7Zo2zrzf9sEbz7vPoNw7vaiZ0w=; b=ahWSomHfbWTYzTAJi5HMWKeXJ5C/yhGNDUTkUnwlr3WERuSax3yLHulHLvIioMGCLh HzFSQKyVnRpPDwm2d4cIvJSKlbcv4cgCEMGfVBUvj83Ew2/66soGF/GVypIRlzahTshI QPuEwWEQxbKItH5MwH+m4GGo+AC5bQiTqrKtlpiUdQf6RDX5l9Wmjd11by8I4pmha/8J Eeed6+xxhWXSVXwkf5VaOJC1MieuaLPuNa/XT8GyR9dA2ZWgfwbO3x11AzIJuyHQwfV/ Pg+aEblpuouruWHh9vX8OyD7AisspCFz402130E1PMlI+l8FpMRV0ASdT+SKoW+B0I+W R1iA== X-Gm-Message-State: AOAM532xXQGNY4p4Ipl9YsjIULoorvaYuX9kNQHAxlTUb2dfwl4Pr0pr 8yPR0yi3F6SRSozbiQ1DfQsmGQZdkKqzHg== X-Google-Smtp-Source: ABdhPJz6sT1sq1a5HcilrPbnzTAgdrQOAcpVCX1p+kHvhuRUkyg82DgrazywIXnSrVck8Tm9q9/kiw== X-Received: by 2002:a05:6808:1524:b0:2ec:f541:cc9d with SMTP id u36-20020a056808152400b002ecf541cc9dmr231991oiw.191.1649097523619; Mon, 04 Apr 2022 11:38:43 -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 x25-20020a056830409900b005af164235b4sm4764978ott.2.2022.04.04.11.38.41 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 04 Apr 2022 11:38:42 -0700 (PDT) Message-ID: <29605c5e-de43-3370-3cee-9d7608cb753f@linaro.org> Date: Mon, 4 Apr 2022 15:38:39 -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> <72332228-093c-5186-789f-8616cfb93793@linaro.org> <0198ce75-8a8e-4355-eed1-f69dfb6f40f0@linaro.org> <939bcfbb-516e-ab97-f6bf-858c4956c38e@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 18:38:46 -0000 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. > >> >> [1] https://www.youtube.com/watch?v=gp_90-3R0pE