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=-0.9 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI 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 C615824C42 for ; Tue, 2 Apr 2024 16:39:28 +0200 (CEST) MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit Received: from layka.disroot.org ([178.21.23.139]) by 9front; Tue Apr 2 10:38:00 -0400 2024 Received: from localhost (localhost [127.0.0.1]) by disroot.org (Postfix) with ESMTP id BDB6740F50 for <9front@9front.org>; Tue, 2 Apr 2024 16:37:55 +0200 (CEST) X-Virus-Scanned: SPAM Filter at disroot.org Received: from layka.disroot.org ([127.0.0.1]) by localhost (disroot.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RD-LLZvs8E45 for <9front@9front.org>; Tue, 2 Apr 2024 16:37:55 +0200 (CEST) Date: Tue, 02 Apr 2024 16:37:53 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=disroot.org; s=mail; t=1712068674; bh=tU+pqo3JqWMoG2FHzWd6RHFaHzZBnSVV8I9jZfCgReE=; h=Date:To:Subject:From:References:In-Reply-To; b=NuKw5P6Om3m3mWGiUS26ppQeMBT2igUW1gLlJ1ILhLhcK67Ed2ggl1wDcNZ2J485v 5WcCzpDsNjbJM01Ug9FUu5BpYCdA0i4hBt2XFU0a5oPe3WipFhqTgHlBnw2pQqX77c OEnpKPSEYHdSt1+Wni2XpB5iJcCWS6jk3JaUES8DyCkHiXXyx0/ps4SJU3N4t7t0H+ tR7qUemphsuVyFE3AObNxkGwJpD625yWEGNMaESu5zbJx8Y1O+Lh14H1Oks1BqHOPr lyE4tcK96OpYSN+CIUQ4p+J5fsPXobf+Qlock+2vrYIzpl0Ix4q7XCqMYTvnOhqnAV qC71ZCnTkIv/w== To: 9front@9front.org From: Eolien55 References: <838AEB3E87F0C2AA5B1CC301A5930F88@wopr.sciops.net> In-Reply-To: <838AEB3E87F0C2AA5B1CC301A5930F88@wopr.sciops.net> Message-Id: <24YLTYTO4Q79Z.243QVQUY1V3P5@e55-lap.my.domain> List-ID: <9front.9front.org> List-Help: X-Glyph: ➈ X-Bullshit: lossless converged HTML over ActivityPub blockchain descriptor Subject: Re: [9front] [PATCH] libc: replace lrand's algorithm Reply-To: 9front@9front.org Precedence: bulk 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. 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. > It's of little use to touch the APE code at all at this point. Alright then, I wasn't sure what was its state in current 9front. > 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 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