From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <9front-bounces@9front.inri.net> X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-4.4 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, NICE_REPLY_A autolearn=ham autolearn_force=no version=3.4.4 Received: from 9front.inri.net (9front.inri.net [168.235.81.73]) by inbox.vuxu.org (Postfix) with ESMTP id 3BBF42671C for ; Wed, 3 Apr 2024 21:52:10 +0200 (CEST) Received: from mimir.eigenstate.org ([206.124.132.107]) by 9front; Wed Apr 3 15:51:04 -0400 2024 Received: from mimir.eigenstate.org (localhost [127.0.0.1]) by mimir.eigenstate.org (OpenSMTPD) with ESMTP id d741215e; Wed, 3 Apr 2024 12:51:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=eigenstate.org; h=date :from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-type:content-transfer-encoding; s=mail; bh=GDuRPiupzQ36Yxn0CrLPLGTwjBU=; b=fmxxn7nY7FLz9F4kaOhemGptMcYw gKw5vp3Z+GMp0dvE8NiHn8Xxmn+sbc9rcDL6sFqE/ha/oliB54BJyRZhFqVnOk2x 5GfUqPx2QW/9SaGKrZkQGQYQk+HEgfaneyzutvORW94CXkf9r03KRaXxu8/txbfC QqsOo8VBNa/Ta0E= DomainKey-Signature: a=rsa-sha1; c=nofws; d=eigenstate.org; h=date:from :to:cc:subject:message-id:in-reply-to:references:mime-version :content-type:content-transfer-encoding; q=dns; s=mail; b=eh6g+k ROgwMAenw0QJiJF2Vud9n4svqL0LA2JHXRIfRaZeGav7h989kToOOg6uYW8V6jZK ONaNqcG3XhETLTByiyenA4fZV6bUWBSDPi2eza0WKpOJ+Suecj3SPcBDUEjbu0Ur K+IxLyLG2qlramnPdwAvQCqE4tONEBpLP5Lkk= Received: from nixos (mail.rmefpc.com [167.206.66.211]) by mimir.eigenstate.org (OpenSMTPD) with ESMTPSA id 9b79ba5a (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256:NO); Wed, 3 Apr 2024 12:51:00 -0700 (PDT) Date: Wed, 3 Apr 2024 15:50:59 -0400 From: Ori Bernstein To: 9front@9front.org Cc: qwx@sciops.net Message-Id: <20240403155059.9ae6ee7e16e6e1cb20020d67@eigenstate.org> In-Reply-To: References: <24YLTYTO4Q79Z.243QVQUY1V3P5@e55-lap.my.domain> X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; x86_64-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit List-ID: <9front.9front.org> List-Help: X-Glyph: ➈ X-Bullshit: ORM over SVG general-purpose-scale callback injection manager Subject: Re: [9front] [PATCH] libc: replace lrand's algorithm Reply-To: 9front@9front.org Precedence: bulk On Wed, 03 Apr 2024 11:07:22 +0200 qwx@sciops.net wrote: > On Tue Apr 2 16:38:36 +0200 2024, eolien55@disroot.org wrote: > > qwx@sciops.net wrote: > > > I like the idea of simplifying the tree and deleting some code, > > > but keep in mind that the xoroshiro128+ variant is what is > > > exposed by /dev/random via truerand(2). > > > > That's not quite it. What is exposed by /dev/random is actually > > a Chacha-based CSPRNG. truerand(2) is a cryptographic PRNG. > > Ah, my bad, sorry. > > > > However, the kernel itself (via tcp, ip, sdp, esp...) uses > > a non-cryptographic PRNG (in nrand and rand calls, in the > > kernel). The kernel's PRNG was changed to xoroshiro128+ > > in 10275ad6dd2. I believe it would make sense to either > > change libc's lrand to xoroshiro128+ too, or to change > > them both at the same time. > [...] > > > Most people are > > > uninsterested in a change here because of the dichotomy between > > > rand and truerand, the negligeable performance impact, etc., > > > and beyond this, it gets into "this is like, my opinion man" > > > territory. I wouldn't mind replacing libc's lrand with a PCG > > > variant also exposing a 64bit version, which we don't have, if > > > it indeed also improves the statistical properties of the prng. > > > But that's like, my opinion man. > > > > Well, this is feasible. Both PCG and xoroshiro require 128 bits > > of state for a 64-bit output. kernel's implementation simulates > > 128-bits operations using 2 64-bit integers. It should be feasible > > to implement a PC64 with the same approach, or to implement > > xoroshiro128+ (or another variant, for statistical quality of the > > lower bits). > > > > I understand the change here is highly subjective, and has > > negligible performance impact (except for seeding/re-seeding). > > I still believe we could, and should, implement a better PRNG > > for libc. Kernel's PRNG has changed; why not libc's? > > > > I found (rand()<<16) + rand() in kernel's devsdp, which is > > strange considering lrand already has 32 bits of output. I > > think this should be considered a bug. > > I think at this point it would be better to look at a patch, with the > changes mentioned after the first post, and a sweep through the other > implementations. There are some odd occurrences as you found; libc's > frand() is also somewhat suspect but will likely need to change if > lrand() does. We need a 16bit, 32bit, floating point, and possibly > 64bit variant; this will clean up some code and remove some > redundancies which is always nice. Perhaps take the extreme route and > do *all* of the changes you'd like to see, so we could more easily > discuss each case. We then need to check if there's a performance > impact on non-amd64 arches. For xoroshiro128+ vs. pcg I'd be > interested to know if there's any significant difference between the > two in statistical properties and performance; if we make a change, > it'd be nice to pick the best alternative and make it once and for > all. Code size and simplicity also counts. Is there any other > variant that should be assessed? > > > > > I agree, though again, I don't know what the impact of such > > > a change would be. > > > > Arguably, very negligible. Both use random tests, and quality is > > somewhat important in these context. A little more than in, say, > > fortune(1), but way less than in tls(3). However, venti's randtest > > uses a hard-coded PRNG instead of libc's. > > > > Cheers, > > Elie Le Vaillant > > In that case, I wouldn't touch venti either. There are at least two > projects for replacing venti with a new implementation; imo any such > changes should be made there. > > Cheers, > qwx -- Ori Bernstein