From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from fhigh2-smtp.messagingengine.com (fhigh2-smtp.messagingengine.com [103.168.172.153]) by sourceware.org (Postfix) with ESMTPS id 7459D3858D28 for ; Sat, 23 Mar 2024 14:02:33 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 7459D3858D28 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=owlfolio.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=owlfolio.org ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 7459D3858D28 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=103.168.172.153 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1711202563; cv=none; b=rW1AC+Tvzbonv1HqGIP4oHqeu7oA9noZnopFgOkEz187oeJPVyHkkT2KbKT86C5pSV1zFgksBjlh7Sz+eBk2PUFc5cG29HetcDNGH+UvroyYvkcG3w1MQfBCeR83cmlOpscr67321/WgEnfzgcmI3ccdoqGVvZa2UqUaspA8NHI= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1711202563; c=relaxed/simple; bh=PeqAFhxaKXmQm500Dmnc8cd98NVlckViTt44Ir+023I=; h=DKIM-Signature:DKIM-Signature:MIME-Version:Message-Id:Date:From: To:Subject; b=v37m1+yMB650XtJk3or7xb4UzyfPWILgE3YaEtOOp1OY81MX00tJRYS65MVXfMM3IbpjgrvecEmrZvVr/oeWTxI7xZGWb9s9ZAFo/0VinPyUdBG9QWFXMlyGx3coXHM37wQvBY+M8ophrsGkJhTigCE5Mg9c2BdyTlGtJNYkbns= ARC-Authentication-Results: i=1; server2.sourceware.org Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailfhigh.nyi.internal (Postfix) with ESMTP id 2B2D811400B1; Sat, 23 Mar 2024 10:02:33 -0400 (EDT) Received: from imap45 ([10.202.2.95]) by compute5.internal (MEProxy); Sat, 23 Mar 2024 10:02:33 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=owlfolio.org; h= cc:cc:content-type:content-type:date:date:from:from:in-reply-to :in-reply-to:message-id:mime-version:references:reply-to:subject :subject:to:to; s=fm1; t=1711202553; x=1711288953; bh=Rim6rY6/F6 NXhJ80nE7AZwZOofHgJ4XjGxYIHtAyI0c=; b=gKouhseuqu6xIfcFnVuti6z9of yd7duaYd1UsAtCNmGQIm7fahiXDMHoRfqElW/+YExGU+QNmZ4GF3zOh+QnksEnZY TIPM9Uxu9NIwdZ+B1Usy+OUXlkXcpMxlWmOtU8gKSQrpYSIXWIhzgkv5j5FkvQ0a 8RX0RCj9ZmpQYt0izjPyNomhGe0o0zg8QPeG8L/NwskDw8OCzIm6yskF3j5kYmpi cvoXsWtJnw9zuwHl7qKqH8q8QGYGxV0k6Cz0iVFUT3am7/G4uSc8mcE+0mRm8xq2 QZvaXyo7OoWqX4pmBMzYeU26qVli5VucEmB3v9c5f9H4BjRnoWgKmgK+1A0g== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:subject:subject:to :to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm2; t=1711202553; x=1711288953; bh=Rim6rY6/F6NXhJ80nE7AZwZOofHg J4XjGxYIHtAyI0c=; b=XYV6+ln1xoUWxivMjVE9ZGuR+ARlFVkPQlBYPZonOtlX 8gmSWsAUfa7oX0m+i1HggfXbAN3TgqrFJVo5F42HFbbadcxelqqNcGOjjmfY5rCN tzA3/QZd6jiX6b3EoG8QGYOd8E3VTUWzqWhVjsbv5/inUVo34NkY4wtsU3j2BceH vkWhgXu4m0nbYTrGeB0WyHXgTJqU6CvKxQO+mWNPwvTY3PuoHv03sRBMfOFdEl2d mCvc+tHWqorNc3CF1djlhrWK6yvykXsPAeZD2a63cD5+4YRwahF9aHLmky+gJULK tytnJvQvuDPOfL2ce3MlSvYPVijJtAAniUW3fFI0Jw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvledruddtgedgiedtucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvfevufgtsehttdertderredtnecuhfhrohhmpedfkggr tghkucghvghinhgsvghrghdfuceoiigrtghksehofihlfhholhhiohdrohhrgheqnecugg ftrfgrthhtvghrnhepueehieduhefhueekgfegfeeuieegvdekgeekffetvdelheehheet fffhveejgeefnecuffhomhgrihhnpehunhhimhhirdhithenucevlhhushhtvghrufhiii gvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpeiirggtkhesohiflhhfohhlihhordho rhhg X-ME-Proxy: Feedback-ID: i876146a2:Fastmail Received: by mailuser.nyi.internal (Postfix, from userid 501) id 5908E272007D; Sat, 23 Mar 2024 10:02:32 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.11.0-alpha0-332-gdeb4194079-fm-20240319.002-gdeb41940 MIME-Version: 1.0 Message-Id: <1ebd177e-8ad0-4bf1-84ea-40586bc3b00c@app.fastmail.com> In-Reply-To: <6a938fb2-30a5-4589-9b58-10828823df6f@efficios.com> References: <89b53f94-075f-4a34-99df-778271965de9@linaro.org> <878r2c11au.fsf@oldenburg.str.redhat.com> <40f9403d-5edc-47ae-8560-6549753ebf39@linaro.org> <17ac36a5-d5c0-4f71-8cf3-5eaf014194d6@linaro.org> <667f5ebb-13e5-4110-a002-3b2b0dfc2bdb@app.fastmail.com> <50b42519-4557-4e8c-8a58-0077168aa25d@linaro.org> <6a938fb2-30a5-4589-9b58-10828823df6f@efficios.com> Date: Sat, 23 Mar 2024 10:01:53 -0400 From: "Zack Weinberg" To: "Mathieu Desnoyers" , "Adhemerval Zanella" , =?UTF-8?Q?Cristian_Rodr=C3=ADguez?= , "Florian Weimer" Cc: "Wilco Dijkstra" , "GNU libc development" , "Jason A. Donenfeld" Subject: Re: [PATCH 2/2] Add single-threaded fast path to rand() Content-Type: text/plain X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,JMQ_SPF_NEUTRAL,RCVD_IN_DNSWL_LOW,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On Fri, Mar 22, 2024, at 3:47 PM, Mathieu Desnoyers wrote: > On 2024-03-22 14:05, Adhemerval Zanella Netto wrote: >> On 22/03/24 12:30, Zack Weinberg wrote: >>> I would describe that as a "CSPRNG with a known bug that makes it >>> unsuitable for use under some conditions", but not as "not a CSPRNG". ... >> I tend to agree, but the contention point was really 'that makes it >> unsuitable for use under some conditions' was a deal breaker in face that >> kernel provides an API with better guarantees. How strong exactly are the guarantees that OpenBSD provides for its arc4random? I don't think we *need* to do any better than that, although obviously we should if we can. >>> On a related note, why is MADV_WIPEONFORK not adequate "feedback from the >>> kernel"? >> If I recall correctly, the problem was not only state wipe on fork (with >> MADV_WIPEONFORK should take care), but rather when the state needs to be >> reseed due various situations outside of the userland knowledge ... > If the goal is to let userspace know that it needs to reseed due to > various kernel events happening, one way I see we could extend rseq > to support this would be to add a 64-bit "seed generation counter" > in the struct rseq per-thread area which would be incremented by the > kernel when the seed needs to be updated in userspace. I don't know hardly anything about rseq. I think that sounds workable from libc's side of the fence; the remaining questions I see are 1) Will the kernel take your patch? 2) Is it OK for us to provide an arc4random implementation that uses this generation counter when available, but, when it's not available, doesn't reseed on these events that are invisible to user space? --- Independently, I propose that the existing non-cryptographic PRNGs (rand(), random(), etc.) should all be changed to run off a thread-local scrambled-linear generator (https://vigna.di.unimi.it/ftp/papers/ScrambledLinear.pdf). These have better statistical properties than anything we currently offer, and a state space that's small enough (256 bits) that it's reasonable for us to have one per thread, obviating locking concerns. zw