NetBSD Problem Report #58044

From www@netbsd.org  Sat Mar 16 20:48:54 2024
Return-Path: <www@netbsd.org>
Received: from mail.netbsd.org (mail.netbsd.org [199.233.217.200])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits))
	(Client CN "mail.NetBSD.org", Issuer "mail.NetBSD.org CA" (not verified))
	by mollari.NetBSD.org (Postfix) with ESMTPS id 84FA21A924F
	for <gnats-bugs@gnats.NetBSD.org>; Sat, 16 Mar 2024 20:48:54 +0000 (UTC)
Message-Id: <20240316204731.8116E1A9250@mollari.NetBSD.org>
Date: Sat, 16 Mar 2024 20:47:31 +0000 (UTC)
From: campbell+netbsd@mumble.net
Reply-To: campbell+netbsd@mumble.net
To: gnats-bugs@NetBSD.org
Subject: revisit whether RND_TYPE_NET should have collection disabled by default
X-Send-Pr-Version: www-1.0

>Number:         58044
>Category:       kern
>Synopsis:       revisit whether RND_TYPE_NET should have collection disabled by default
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Sat Mar 16 20:50:00 +0000 2024
>Last-Modified:  Sat Mar 16 22:15:02 +0000 2024
>Originator:     Taylor R Campbell
>Release:        current, 10
>Organization:
The NetBSD Entropation
>Environment:
>Description:
By default, all RND_TYPE_NET sources have collection disabled by default:

   1783 	/*
   1784 	 * Apply some standard flags:
   1785 	 *
   1786 	 * - We do not bother with network devices by default, for
   1787 	 *   hysterical raisins (perhaps: because it is often the case
   1788 	 *   that an adversary can influence network packet timings).
   1789 	 */
   1790 	switch (type) {
   1791 	case RND_TYPE_NET:
   1792 		flags |= RND_FLAG_NO_COLLECT;
   1793 		break;
   1794 	}

https://nxr.netbsd.org/xref/src/sys/kern/kern_entropy.c?r=1.66#1783

This has been the case since 1999, in sys/dev/rnd.c 1.14:

commit c1ab1c57fb4c8242b7cd6492b70c7fe3c5148893
Author: explorer <explorer@NetBSD.org>
Date:   Sun Feb 28 19:01:30 1999 +0000

    don't collect or estimate on network devices by default
...
--- a/sys/dev/rnd.c
+++ b/sys/dev/rnd.c
@@ -1,4 +1,4 @@
-/*	$NetBSD: rnd.c,v 1.13 1999/02/28 17:19:13 explorer Exp $	*/
+/*	$NetBSD: rnd.c,v 1.14 1999/02/28 19:01:30 explorer Exp $	*/

 /*-
  * Copyright (c) 1997 The NetBSD Foundation, Inc.
@@ -716,7 +716,7 @@ rnd_attach_source(rs, name, type, flags)
 	 * default
 	 */
 	if (type == RND_TYPE_NET)
-		flags |= RND_FLAG_NO_ESTIMATE;
+		flags |= (RND_FLAG_NO_COLLECT | RND_FLAG_NO_ESTIMATE);


http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/dev/Attic/rnd.c?only_with_tag=MAIN#rev1.14

Estimation has also been disabled by default for RND_TYPE_NET sources since 1997, in sys/dev/rnd.c 1.2:

commit e4e727226cd4d32825373bd431d93dd7139e9f86
Author: explorer <explorer@NetBSD.org>
Date:   Fri Oct 10 16:35:00 1997 +0000

    For network devices, collect timing information and mix into the pool,
    but do not assume any entopy is gathered.  It can be enabled using an
    IOCTL again if the user desires.

    Note that the mix function uses xor, so at worse an attacker can twiddle
    bits in the pool, but not into a known state assuming it started as
    an unknown.
...
--- a/sys/dev/rnd.c
+++ b/sys/dev/rnd.c
@@ -1,4 +1,4 @@
-/*	$NetBSD: rnd.c,v 1.1 1997/10/09 23:13:12 explorer Exp $	*/
+/*	$NetBSD: rnd.c,v 1.2 1997/10/10 16:35:00 explorer Exp $	*/

 /*-
  * Copyright (c) 1997 The NetBSD Foundation, Inc.
@@ -580,6 +580,13 @@ rnd_attach_source(rs, name, tyfl)
 {
 	strcpy(rs->data.name, name);

+	/*
+	 * force network devices to not collect any entropy by
+	 * default
+	 */
+	if ((tyfl & 0x00ff) == RND_TYPE_NET)
+		tyfl |= RND_FLAG_NO_ESTIMATE;
+

http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/dev/Attic/rnd.c?only_with_tag=MAIN#rev1.2

Arguments against collecting any data, which may have justified this in the past:

1. Generally, we expect adversaries can send network packets (and control their timing) even if they can't control disk queries, local environmental sensors, &c.
2. Entering samples into the pool has some computational cost, and this conflicts with high-throughput networking.

Present counterarguments:

1. Whether the samples are _collected_ can be controlled independently of whether the samples are _counted_ for anything.  (In these cases, they are counted as zero bits, but up to one sample, depending on the time-delta entropy estimator applied to the timing of the sample, which is used for the purpose of unblocking /dev/random.)
2. Collecting samples should scale much better now that it's not bottlenecked on a global lock, and the mixing operation no longer contributes to hard interrupt latency.  (That said, it does still contribute to soft interrupt latency, and maybe the Keccak stirring operation is costly enough for that to matter.)
3. The code is simpler if we delete this RND_TYPE_NET-specific logic.
>How-To-Repeat:
rndctl -l
>Fix:
1. Make a decision.
2. Implement it.

>Audit-Trail:
From: matthew green <mrg@eterna23.net>
To: gnats-bugs@netbsd.org
Cc: kern-bug-people@netbsd.org, gnats-admin@netbsd.org,
    netbsd-bugs@netbsd.org
Subject: re: kern/58044: revisit whether RND_TYPE_NET should have collection disabled by default
Date: Sun, 17 Mar 2024 09:14:46 +1100

 i'm of the opinion we should enable it by default.

 to me, the only real argument against is performance, and as long
 as it is not hard to disable, then the real use-case is handled.

Home	PR Database Search