From nobody Sun May 5 13:39:19 2024 Delivered-To: importer@patchew.org Received-SPF: pass (zoho.com: domain of gnu.org designates 209.51.188.17 as permitted sender) client-ip=209.51.188.17; envelope-from=qemu-devel-bounces+importer=patchew.org@nongnu.org; helo=lists.gnu.org; Authentication-Results: mx.zohomail.com; spf=pass (zoho.com: domain of gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=qemu-devel-bounces+importer=patchew.org@nongnu.org; dmarc=fail(p=none dis=none) header.from=redhat.com ARC-Seal: i=1; a=rsa-sha256; t=1557476216; cv=none; d=zoho.com; s=zohoarc; b=AALrs7nb2bi6Y3Ywdp/t1lbQFwWaeKhgYkBhKANHYaRwUzhWnmnBnvjZOhkg7f//2rDw6zR3al8teKY3nlDY9qmGfrdLGOQ2OzXKLUORwhe4uC7tMSH0+XoGHyVQbA9wwJb01GSzvmJrE/09hrK4zsgAGxqRsp4AVWm7Dst+oeo= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zoho.com; s=zohoarc; t=1557476216; h=Cc:Date:From:List-Subscribe:List-Post:List-Id:List-Archive:List-Help:List-Unsubscribe:Message-ID:Sender:Subject:To:ARC-Authentication-Results; bh=0gBsAHdh2HG4k7t+YWRD5HM7pcQSN0gI4yOdG3hwUt4=; b=f71bVdmO9ojkm9LsH3vY4+Ji6q15UdaQpVo8WcdqwGwFoV4qgH7iZioiUH2b5SK59/V/Ns4QbPqx7bCouWI6ZdowT0CKLwebmBXQz5Co218zt8oXSAI4oTVa6MrWtOTDj5TlmU9cx4oXXoGtk4kJe8LeL0RnvtqOddUcEy9SWXQ= ARC-Authentication-Results: i=1; mx.zoho.com; spf=pass (zoho.com: domain of gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=qemu-devel-bounces+importer=patchew.org@nongnu.org; dmarc=fail header.from= (p=none dis=none) header.from= Return-Path: Received: from lists.gnu.org (209.51.188.17 [209.51.188.17]) by mx.zohomail.com with SMTPS id 1557476216206565.8366499963463; Fri, 10 May 2019 01:16:56 -0700 (PDT) Received: from localhost ([127.0.0.1]:38754 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hP0i1-0002lI-My for importer@patchew.org; Fri, 10 May 2019 04:16:49 -0400 Received: from eggs.gnu.org ([209.51.188.92]:57474) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hP0h4-0001tb-3G for qemu-devel@nongnu.org; Fri, 10 May 2019 04:15:51 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hP0gw-0004Fb-Nr for qemu-devel@nongnu.org; Fri, 10 May 2019 04:15:48 -0400 Received: from mx1.redhat.com ([209.132.183.28]:60842) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1hP0gu-0004Au-OM for qemu-devel@nongnu.org; Fri, 10 May 2019 04:15:42 -0400 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id DF94A308421A; Fri, 10 May 2019 08:15:35 +0000 (UTC) Received: from paraplu.localdomain (ovpn-117-82.ams2.redhat.com [10.36.117.82]) by smtp.corp.redhat.com (Postfix) with ESMTP id 3A2E657A1; Fri, 10 May 2019 08:15:31 +0000 (UTC) From: Kashyap Chamarthy To: qemu-devel@nongnu.org Date: Fri, 10 May 2019 10:15:25 +0200 Message-Id: <20190510081526.15507-1-kchamart@redhat.com> X-Scanned-By: MIMEDefang 2.84 on 10.5.11.23 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.40]); Fri, 10 May 2019 08:15:36 +0000 (UTC) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 209.132.183.28 Subject: [Qemu-devel] [PATCH v2] VirtIO-RNG: Update default entropy source to `/dev/urandom` X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Kashyap Chamarthy , amit@kernel.org, rjones@redhat.com, armbru@redhat.com, stefanha@redhat.com Errors-To: qemu-devel-bounces+importer=patchew.org@nongnu.org Sender: "Qemu-devel" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" When QEMU exposes a VirtIO-RNG device to the guest, that device needs a source of entropy, and that source needs to be "non-blocking", like `/dev/urandom`. However, currently QEMU defaults to the problematic `/dev/random`, which is "blocking" (as in, it waits until sufficient entropy is available). Why prefer `/dev/urandom` over `/dev/random`? Reviewed-by: Daniel P. Berrang=C3=A9 Reviewed-by: Stefan Hajnoczi --------------------------------------------- The man pages of urandom(4) and random(4) state: "The /dev/random device is a legacy interface which dates back to a time where the cryptographic primitives used in the implementation of /dev/urandom were not widely trusted. It will return random bytes only within the estimated number of bits of fresh noise in the entropy pool, blocking if necessary. /dev/random is suitable for applications that need high quality randomness, and can afford indeterminate delays." Further, the "Usage" section of the said man pages state: "The /dev/random interface is considered a legacy interface, and /dev/urandom is preferred and sufficient in all use cases, with the exception of applications which require randomness during early boot time; for these applications, getrandom(2) must be used instead, because it will block until the entropy pool is initialized. "If a seed file is saved across reboots as recommended below (all major Linux distributions have done this since 2000 at least), the output is cryptographically secure against attackers without local root access as soon as it is reloaded in the boot sequence, and perfectly adequate for network encryption session keys. Since reads from /dev/random may block, users will usually want to open it in nonblocking mode (or perform a read with timeout), and provide some sort of user notification if the desired entropy is not immediately available." And refer to random(7) for a comparison of `/dev/random` and `/dev/urandom`. - - - Given the above, change the entropy source for VirtIO-RNG device to `/dev/urandom`. Related discussion in these[1][2] past threads. [1] https://lists.nongnu.org/archive/html/qemu-devel/2018-06/msg08335.html -- "RNG: Any reason QEMU doesn't default to `/dev/urandom`?" [2] https://lists.nongnu.org/archive/html/qemu-devel/2018-09/msg02724.html -- "[RFC] Virtio RNG: Consider changing the default entropy source to /dev/urandom" Signed-off-by: Kashyap Chamarthy --- v2: - Update commit message to mention justification for preferring `/dev/urandom` over `/dev/random` [stefanha] --- backends/rng-random.c | 2 +- qemu-options.hx | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/backends/rng-random.c b/backends/rng-random.c index e2a49b0571d79eab335d5a74841d92c50a727b6a..eff36ef14084bccaad1eabe952e= 2cf6ffa9a2529 100644 --- a/backends/rng-random.c +++ b/backends/rng-random.c @@ -112,7 +112,7 @@ static void rng_random_init(Object *obj) rng_random_set_filename, NULL); =20 - s->filename =3D g_strdup("/dev/random"); + s->filename =3D g_strdup("/dev/urandom"); s->fd =3D -1; } =20 diff --git a/qemu-options.hx b/qemu-options.hx index 51802cbb266a208d70989c4f0ab3317a76edc1ea..a525609149e4d0e4bb60959f029= a1a16eb36900d 100644 --- a/qemu-options.hx +++ b/qemu-options.hx @@ -4276,7 +4276,7 @@ Creates a random number generator backend which obtai= ns entropy from a device on the host. The @option{id} parameter is a unique ID that will be used to reference this entropy backend from the @option{virtio-rng} device. The @option{filename} parameter specifies which file to obtain -entropy from and if omitted defaults to @option{/dev/random}. +entropy from and if omitted defaults to @option{/dev/urandom}. =20 @item -object rng-egd,id=3D@var{id},chardev=3D@var{chardevid} =20 --=20 2.17.2