From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-yb1-xb30.google.com (mail-yb1-xb30.google.com [IPv6:2607:f8b0:4864:20::b30]) by sourceware.org (Postfix) with ESMTPS id 3EDEB3858D37 for ; Mon, 4 Apr 2022 19:16:39 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 3EDEB3858D37 Received: by mail-yb1-xb30.google.com with SMTP id j2so19552163ybu.0 for ; Mon, 04 Apr 2022 12:16:39 -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=zZ+MbARHAHCacWA31EQ5mK3R3GkfuvA/sC/dKWxI11M=; b=CpJNnXqpNsqVCHp0Dij9HetTuBzQ0leJxl/BXhuGE1Lr2Y0sp9V6b4wCDbe5qXGYZm tcUmCxa2xRy+Xj9PbO395zVGZs1RqAAI649BdAaqzgOQRh65QNFDd/UeuUD3O1+KtTfY NFnx+oukhFqNX4ReOCA5zMKVc63AfEDT2NlVBDtF2xas4+eDIFPg2DVBg8kGj2ClKuBf PJdwQHxNwMo++dJX4lqRgmyv2fotveTITIYCbgNcy8RroM8rD419cy3tdfRdRO9CFI4n p4txLxrdUAOzrQz2CQUQSzRprDe+3hudF5O6j+rwFJBLIRCUHMKVblsdWwhmvW2ceX13 TJmg== X-Gm-Message-State: AOAM532ecQCzzyZ1Zy/5xNRImg5iadfUhWIzro3Crv6g4F+D5Dr6syXC 5ZlN4hSVWXFuOklb6ISHb2QZ5x+Ie/oPp81nNWI= X-Google-Smtp-Source: ABdhPJy1hsw5h9FZRCICjMwTGUxxDMr7IBgYfRASGyEtbYVp5Ui+ZHynHqkcF30uzpF9EPWQPVpiieYP0SlBQ3/p8y0= X-Received: by 2002:a05:6902:388:b0:629:2185:e172 with SMTP id f8-20020a056902038800b006292185e172mr1126887ybs.611.1649099798649; Mon, 04 Apr 2022 12:16:38 -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> <87h7786gwy.fsf@oldenburg.str.redhat.com> <87a6d06ghc.fsf@oldenburg.str.redhat.com> In-Reply-To: From: Noah Goldstein Date: Mon, 4 Apr 2022 14:16:27 -0500 Message-ID: Subject: Re: [PATCH v1 1/2] random-bits: Factor out entropy generating function To: "Jason A. Donenfeld" Cc: Florian Weimer , "Jason A. Donenfeld via Libc-alpha" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-2.4 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 19:16:44 -0000 On Mon, Apr 4, 2022 at 1:32 PM Jason A. Donenfeld wrote: > > Hi Noah, > > On Mon, Apr 4, 2022 at 6:51 PM Noah Goldstein w= rote: > > > > On Mon, Apr 4, 2022 at 10:00 AM Florian Weimer via Libc-alpha > > wrote: > > > > > > * Jason A. Donenfeld via Libc-alpha: > > > > > > > _However_, based on what people have said in this thread, this all > > > > seems highly unnecessary, since you just need some boring > > > > statistically uniform randomness without any crypto or security > > > > requirements of any kind, and it simply needs to be fast and dumb. = If > > > > that's the wrong set of requirements for this problem (I still have= no > > > > idea what the bigger picture here is), please pipe up. > > > > > > If we can make a cryptographically secure generator fast enough, it > > > would relieve programmers of the need to choose between that and anot= her > > > generator that just gives some random-looking bits fast. If programm= ers > > > don't have to make a choice, they can't choose incorrectly (introduci= ng > > > performance bugs or security bugs). > > > > It sounds like you're talking about creating a user facing API. Since > > random_bits > > is internal do we really need so much ease of use at the cost of perfor= mance? > > Right, my thoughts exactly. If you just need some statistically > uniform bytes for whatever it is whomever told me above something > about threading something about no security something about really > doesn't matter, then I fail to see why https://=D7=90.cc/xrAIhCvy/c is > insufficient, and I also don't know why this thread is chasing its > tail about rdtsc. > > I'd appreciate it if somebody in a leadership position could let me > know what is asked of me here, since somebody CC'd me into this > thread. I've already made two RNGs here for various spitballed > objectives. I'd like to refrain from spending time on a third until > there's some clarity on what it is you all want. Probably it makes > sense for me to leave this thread alone for a bit while you guys work > that out. > Sorry it seems this thread has diverged in several directions. Think a seperate thread for the arc4random stuff would be better as its really its own thing. Regarding this patch which aims at making it easier to provide a lighter-weight random_bits function. Your code seems to make sense for systems without VDSO or some arch alternative that can be used to avoid syscalls. Generally my thought it saving the static storage (TLS really) is worth it so I'd prefer to keep the per-arch interface and make your code the generic solution but thats up for debate. Particularly arch specific is harder to maintain and this function is not particularly hot. So I see four possibilities: 1. Drop it. 2. Generic solution only (using code based on Jason's solution) 3. This patch and update generic solution with Jason's solution 4. This patch and keep gettime for the generic solution Anyone have opinions of 1/2/3/4? If not I'm partial to 3. > Jason