From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pf1-x429.google.com (mail-pf1-x429.google.com [IPv6:2607:f8b0:4864:20::429]) by sourceware.org (Postfix) with ESMTPS id 75A32385840C for ; Wed, 30 Mar 2022 16:30:31 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 75A32385840C Received: by mail-pf1-x429.google.com with SMTP id w7so16506671pfu.11 for ; Wed, 30 Mar 2022 09:30:31 -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; bh=3yaYcYLunB39IMoCx28DIXajjgWrPKfZDkDPC2yVFtM=; b=LLV3jh9Zn8KnzbUuqfjZoItK71To64wDtM/T7RusLSrKmtwEmvy415zWuavgh4ivYa kdoCqesIhNm1J2dEO7/Mt20+VqL7s4EtzmfnmxJCRDCt77GoZyMOA5TWQvMz6+IHVCBb WySwPNEX1LsLzQm+uhmWuDX3Kqil8QHU8FfaAKV18XoDJ0S7hTKj2uRPBeisHDYhaNgy jagZMZu73/th+zkTByMv17b/dE9GbYIpAJgfj7+NtxLydnWv9MHYJ8qrNC+0EBfPpSR+ aHk1l7xdTaLA/MME8+HmLi4Xf3GNwPEIfwL6mQMBYmwmeWbPvbyOJYrZGpHVdLcERLIm gb9g== X-Gm-Message-State: AOAM530318QYmWKpXZy9lBromNGwWYi1MDZVNQtsz7m73XvgIO2idaHp i6zORH08XCImRHgKXwL3rvlbmwFHskYzMBvvaks7EZjv X-Google-Smtp-Source: ABdhPJxdaVaGE91qBg69qc1zUVPzdZSTPZkHvBJPTq3NWfefrjDXFqLEVhSC3iCMu4B7wrLR6kyouFc6avhgca/zvRE= X-Received: by 2002:a62:1c8d:0:b0:4fa:8dcb:6da2 with SMTP id c135-20020a621c8d000000b004fa8dcb6da2mr202239pfc.19.1648657830145; Wed, 30 Mar 2022 09:30:30 -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> In-Reply-To: <72332228-093c-5186-789f-8616cfb93793@linaro.org> From: Noah Goldstein Date: Wed, 30 Mar 2022 11:30:19 -0500 Message-ID: Subject: Re: [PATCH v1 1/2] random-bits: Factor out entropy generating function To: Adhemerval Zanella Cc: GNU C Library Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-9.8 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, GIT_PATCH_0, 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: Wed, 30 Mar 2022 16:30:33 -0000 On Wed, Mar 30, 2022 at 10:37 AM Adhemerval Zanella wrote: > > > > On 29/03/2022 17:44, Noah Goldstein wrote: > > On Tue, Mar 29, 2022 at 3:37 PM Adhemerval Zanella > > wrote: > >> > >> > >> > >> On 29/03/2022 16:56, Noah Goldstein wrote: > >>> On Tue, Mar 29, 2022 at 2:51 PM Adhemerval Zanella > >>> wrote: > >>>> > >>>> > >>>> > >>>> On 28/03/2022 19:09, Noah Goldstein via Libc-alpha wrote: > >>>>> On some architectures `clock_gettime` is undesirable as > >>>>> it may use a syscall or there may be a faster alternative. > >>>>> Future architecture specific functions can be added in > >>>>> sysdeps//random-bits-entropy.h to provide a version of > >>>>> 'random_bits_entropy' that doesn't use 'clock_gettime'. > >>>>> --- > >>>>> include/random-bits.h | 16 ++++++-------- > >>>>> sysdeps/generic/random-bits-entropy.h | 31 +++++++++++++++++++++++++++ > >>>>> 2 files changed, 37 insertions(+), 10 deletions(-) > >>>>> create mode 100644 sysdeps/generic/random-bits-entropy.h > >>>>> > >>>>> diff --git a/include/random-bits.h b/include/random-bits.h > >>>>> index 17665b479a..016b87576c 100644 > >>>>> --- a/include/random-bits.h > >>>>> +++ b/include/random-bits.h > >>>>> @@ -19,21 +19,17 @@ > >>>>> #ifndef _RANDOM_BITS_H > >>>>> # define _RANDOM_BITS_H > >>>>> > >>>>> -#include > >>>>> -#include > >>>>> +# include > >>>>> +# include > >>>>> > >>>>> -/* Provides fast pseudo-random bits through clock_gettime. It has unspecified > >>>>> - starting time, nano-second accuracy, its randomness is significantly better > >>>>> - than gettimeofday, and for mostly architectures it is implemented through > >>>>> - vDSO instead of a syscall. Since the source is a system clock, the upper > >>>>> - bits will have less entropy. */ > >>>>> +/* Provides fast pseudo-random bits through architecture specific > >>>>> + random_bits_entropy. Expectation is source is some timing function so > >>>>> + the upper bits have less entropy. */ > >>>>> static inline uint32_t > >>>>> random_bits (void) > >>>>> { > >>>>> - struct __timespec64 tv; > >>>>> - __clock_gettime64 (CLOCK_MONOTONIC, &tv); > >>>>> + uint32_t ret = random_bits_entropy (); > >>>>> /* Shuffle the lower bits to minimize the clock bias. */ > >>>>> - uint32_t ret = tv.tv_nsec ^ tv.tv_sec; > >>>>> ret ^= (ret << 24) | (ret >> 8); > >>>>> return ret; > >>>>> } > >>>> > >>>> We already provide hp-timing.h, which uses rdtsc on x86 and clock_gettime on > >>>> generic interface (and other high precision timing on other architectures). > >>>> So I think a better way would be to: > >>> > >>> For x86/generic that works but other architectures also have hp-timing > >>> implementations that might not be suitable for this (i.e there might be > >>> an entropy regression). > >> > >> I would expect that the entropy of the hp-timing.h instruction would be similar > >> to the ones from system clock (which exception of legacy architecture like alpha), > >> but I haven't checked yet. > > > > Would expect the same, but think it will probably take a test on a > > per-arch basis. > > > > Also there are optimizations we can make since we only need the lower > > 32-bits and > > not a true timestamp. > > > > I.e no multiply for generic. Also on x86 we can skip combining the > > results of rdtsc. > > I tested the entropy on some different architectures: > > aarch64: > $ ent gettime-random.txt > Entropy = 7.293634 bits per byte. > $ ent hptiming-random.txt > Entropy = 6.451314 bits per byte. > > ia64: > $ ent gettime-random.txt > Entropy = 7.613066 bits per byte. > $ ent hptiming-random.txt > Entropy = 7.458615 bits per byte. > > powerpc64le: > $ ent gettime-random.txt > Entropy = 7.413584 bits per byte. > $ ent hptiming-random.txt > Entropy = 7.243894 bits per byte. > > sparc64 > $ ent gettime-random.txt > Entropy = 7.388590 bits per byte. > $ ent hptiming-random.txt > Entropy = 7.602368 bits per byte. > > > So it seems that only aarch64 is really losing some entropy when using > hp-timing.h (not sure why). Thanks, I can add patches for sparc/powerpc64le/ia64. Still feel that since it takes testing and there are optimization cases that we may want to make it's still best to have a seperate file.