From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oi1-x22c.google.com (mail-oi1-x22c.google.com [IPv6:2607:f8b0:4864:20::22c]) by sourceware.org (Postfix) with ESMTPS id 83E643858C52 for ; Mon, 4 Apr 2022 17:42:45 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 83E643858C52 Received: by mail-oi1-x22c.google.com with SMTP id v75so10838457oie.1 for ; Mon, 04 Apr 2022 10:42:45 -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=x856e1cyGPF07xYwCRRfagzBIh3llWUXeg+WJbk34U4=; b=TKAZZjWjDdy+qlC5Yzy/kNdPAVmDVIC0/TQu9amawLGooX1zgLlHdKPZrXg5yb7Lf4 j11Zr1BLFmRXX/49wA4jCrFtAAZzqfl4Vn4EI4mkuj6dOu6sbg8EL5fmvDNlUfiJupk4 XFZ8y81juqO7F9wvVfgIEa6OlPhPE8NEhU7bHWTjjo2LlOpfFE0YYqbRmWLJKdX6i+NU JvaBdLcXcpXvuMP5PHK45nMMc8LTGl5EuFjFq5iV1kZ9qeyb+yORxRagKblSGb3WpP/1 7a1KXbUtlFU33wXCawDrfPyykS04//2zAZ/RUyPX/Mq2n0yXO8yDejhfVwrdRAYkNDUx /1Pw== X-Gm-Message-State: AOAM5311LZU5RKROwqQKz7gxds86NveDOOCDgvB5sHTih7N1Fk/VBXrd SGaENthEPlUZhwsMtX6DlEY1mg== X-Google-Smtp-Source: ABdhPJw21CXAYgkx/v6mRto8qkfmILCFHcA/fScfXsmWClyz3EUVJmTNjNtM+CO1sRFviyO6ocaMmA== X-Received: by 2002:a05:6808:1b0b:b0:2da:1ea7:e065 with SMTP id bx11-20020a0568081b0b00b002da1ea7e065mr139115oib.284.1649094164690; Mon, 04 Apr 2022 10:42:44 -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 1-20020a056870104100b000dd9a2eb20asm4405155oaj.21.2022.04.04.10.42.42 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 04 Apr 2022 10:42:44 -0700 (PDT) Message-ID: <939bcfbb-516e-ab97-f6bf-858c4956c38e@linaro.org> Date: Mon, 4 Apr 2022 14:42:41 -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: =?UTF-8?Q?Cristian_Rodr=c3=adguez?= , Noah Goldstein Cc: "Jason A. Donenfeld" , GNU C Library , Florian Weimer 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> 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 17:42:47 -0000 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). [1] https://www.youtube.com/watch?v=gp_90-3R0pE