From nobody Thu Feb 17 05:06:01 2022 X-Original-To: dev-commits-src-all@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id BBAAD19D1C39; Thu, 17 Feb 2022 05:06:01 +0000 (UTC) (envelope-from git@FreeBSD.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JzjTP4TV0z571d; Thu, 17 Feb 2022 05:06:01 +0000 (UTC) (envelope-from git@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1645074361; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=ItLcQtRb3Tx4gB6Fz1p8POFdF/Jo41Den/t/ghDhJwM=; b=mP41ndgem49PFcS3LP0s5fE9nbp0I+iKFJcjw2T2yr3rBg+otsExp0POpnsEwudCMuH3Ff f8SzaqEQcH77JIrtQAjOip0T2DaoPQ+Zyi0/ntmJq5WafSBqj46v8iA3R96SlJtOprMABG 8TIiYtXw7OT6yS9+kS6WZa8o0GYteiDtHeW//7P8wxwjpNh1+MDhoMSgpaLKEFXQforHPq S1djOwCR98EqNkB993Q1pTk4lLBNtvIz9mjmDAwuo/wRVfv+bQjt4LzynjMrF3MJN2IFA3 na+571IEELPkqNkGF2FkidFQA7nAPhMNnC+0MvTby5ZV99+AzqX9pnq+WBLeLQ== Received: from gitrepo.freebsd.org (gitrepo.freebsd.org [IPv6:2610:1c1:1:6068::e6a:5]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 7129423A4E; Thu, 17 Feb 2022 05:06:01 +0000 (UTC) (envelope-from git@FreeBSD.org) Received: from gitrepo.freebsd.org ([127.0.1.44]) by gitrepo.freebsd.org (8.16.1/8.16.1) with ESMTP id 21H561Sr050722; Thu, 17 Feb 2022 05:06:01 GMT (envelope-from git@gitrepo.freebsd.org) Received: (from git@localhost) by gitrepo.freebsd.org (8.16.1/8.16.1/Submit) id 21H561dX050721; Thu, 17 Feb 2022 05:06:01 GMT (envelope-from git) Date: Thu, 17 Feb 2022 05:06:01 GMT Message-Id: <202202170506.21H561dX050721@gitrepo.freebsd.org> To: src-committers@FreeBSD.org, dev-commits-src-all@FreeBSD.org, dev-commits-src-branches@FreeBSD.org From: "David E. O'Brien" Subject: git: d84d8a42e9dc - stable/12 - random(4): Fortuna: Update concurrent generation documentation List-Id: Commit messages for all branches of the src repository List-Archive: https://lists.freebsd.org/archives/dev-commits-src-all List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-dev-commits-src-all@freebsd.org X-BeenThere: dev-commits-src-all@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Git-Committer: obrien X-Git-Repository: src X-Git-Refname: refs/heads/stable/12 X-Git-Reftype: branch X-Git-Commit: d84d8a42e9dc1b23c494514172074f15817f1ac2 Auto-Submitted: auto-generated ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1645074361; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=ItLcQtRb3Tx4gB6Fz1p8POFdF/Jo41Den/t/ghDhJwM=; b=f+YY4EFtavllW0zZseTHsC8Z8i1IKEgIbZ5IOfaDEggroQbprHKFCsYqHr0dfKcqe3mRpM iaNYMSpt7mFUbcdfoMUdN2Zhje9xm4u3O/dW49qNXaRMQXIIZI7aozcUXLnUSGbGWGkSDk Ymo+2xaPs3FGLNK9veLPeD012QGPLYKI0G3Kn+ehS2TdU6bkFWuhOMIG7Q+9d781HxuELK Ln7EoPQB4DYhZSUXGT6U3gHe0357kTT7IbD3AW4LTR0rO0SVeapJPJnF2xlk6pYfyMxPJG jTfGSYdKwAQoKCSqPSQ8L9ToaBFa7K7br25DJc67I6YTDbxvp97RtyFvDA108A== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1645074361; a=rsa-sha256; cv=none; b=ke6e5rPXdBSDMcOMcla7QuxhC7ZCcf2VSPM0kRhzPO3/ltR3O4dcKrzSSwqhAid+hJqK+/ 3Exw/Vi3LwjvkwrBMsP1L2rjrJqXBn/mqesoRFB9bIbtyXn/0yI8svYUToty1U7NnxRHiu YfDnrXMcfCjbD75U9KtF5YznOJYKCheIvhG1h1B2r3+mH7fqqXysiYRXkBkeO4aIq4q6v6 8vIGpAKQQaSmQqYK3hPJ/4/HzmG8WmTHUl3p46lXkvkdr8kjXwALpwR0rJy6x8BKYkm1iz SeM3nk1YW51gi+peg0f6Wwd+ISablYgkX7GPOG2b62Gysh6VELFuVQHlzlIIxw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N The branch stable/12 has been updated by obrien: URL: https://cgit.FreeBSD.org/src/commit/?id=d84d8a42e9dc1b23c494514172074f15817f1ac2 commit d84d8a42e9dc1b23c494514172074f15817f1ac2 Author: Conrad Meyer AuthorDate: 2019-12-20 08:31:23 +0000 Commit: David E. O'Brien CommitDate: 2022-02-17 04:57:46 +0000 random(4): Fortuna: Update concurrent generation documentation The knob added in r349154 remains "disabled." The commit message from that revision and associated code comment describe the rationale, implementation, and motivation for the new option in detail. For end-users: if you enable this, the result is just as secure. The benefit is a faster, more responsive system when processes produce significant demand on random(4). As mentioned in the earlier commit, the prior behavior may be enabled by setting the kern.random.fortuna.concurrent_read="1" knob in loader.conf(5). This scales the random generation side of random(4) somewhat, although there is still a global mutex being shared by all cores and rand_harvestq; the situation is generally much better than it was before on small CPU systems, but do not expect miracles on 256-core systems running 256-thread full-rate random(4) read. (cherry picked from commit 548dca90ae2fc3c0900c94a97e89aa97d6c36eae) --- sys/dev/random/fortuna.c | 26 +++++++++++++++----------- 1 file changed, 15 insertions(+), 11 deletions(-) diff --git a/sys/dev/random/fortuna.c b/sys/dev/random/fortuna.c index f93cf7145ca3..52e93a594014 100644 --- a/sys/dev/random/fortuna.c +++ b/sys/dev/random/fortuna.c @@ -125,14 +125,14 @@ static struct fortuna_state { } fortuna_state; /* - * This knob enables or disables Concurrent Reads. The plan is to turn it on - * by default sometime before 13.0 branches. + * This knob enables or disables the "Concurrent Reads" Fortuna feature. * - * The benefit is improved concurrency in Fortuna. That is reflected in two - * related aspects: + * The benefit of Concurrent Reads is improved concurrency in Fortuna. That is + * reflected in two related aspects: * - * 1. Concurrent devrandom readers can achieve similar throughput to a single - * reader thread. + * 1. Concurrent full-rate devrandom readers can achieve similar throughput to + * a single reader thread (at least up to a modest number of cores; the + * non-concurrent design falls over at 2 readers). * * 2. The rand_harvestq process spends much less time spinning when one or more * readers is processing a large request. Partially this is due to @@ -142,16 +142,20 @@ static struct fortuna_state { * mutexes assume that a lock holder currently on CPU will release the lock * quickly, and spin if the owning thread is currently running. * + * (There is no reason rand_harvestq necessarily has to use the same lock as + * the generator, or that it must necessarily drop and retake locks + * repeatedly, but that is the current status quo.) + * * The concern is that the reduced lock scope might results in a less safe * random(4) design. However, the reduced-lock scope design is still * fundamentally Fortuna. This is discussed below. * * Fortuna Read() only needs mutual exclusion between readers to correctly - * update the shared read-side state: just C, the 128-bit counter, and K, the - * current cipher key. + * update the shared read-side state: C, the 128-bit counter; and K, the + * current cipher/PRF key. * * In the Fortuna design, the global counter C should provide an independent - * range of values per generator (CTR-mode cipher or similar) invocation. + * range of values per request. * * Under lock, we can save a copy of C on the stack, and increment the global C * by the number of blocks a Read request will require. @@ -159,7 +163,7 @@ static struct fortuna_state { * Still under lock, we can save a copy of the key K on the stack, and then * perform the usual key erasure K' <- Keystream(C, K, ...). This does require * generating 256 bits (32 bytes) of cryptographic keystream output with the - * global lock held, but that's all; none of the user keystream generation must + * global lock held, but that's all; none of the API keystream generation must * be performed under lock. * * At this point, we may unlock. @@ -210,7 +214,7 @@ static struct fortuna_state { * 2: <- GenBytes() * 2:Unlock() * - * Just prior to unlock, shared state is still identical: + * Just prior to unlock, global state is identical: * ------------------------------------------------------ * * C'''' == (C_0 + N + 1) + M + 1 C'''' == (C_0 + N + 1) + M + 1