From: Filip Schauer <f.schauer@proxmox.com>
To: pve-devel@lists.proxmox.com
Subject: [pve-devel] [PATCH qemu-server v3 08/11] refactor: move rng related code into its own module
Date: Mon, 10 Feb 2025 16:37:31 +0100 [thread overview]
Message-ID: <20250210153734.103381-9-f.schauer@proxmox.com> (raw)
In-Reply-To: <20250210153734.103381-1-f.schauer@proxmox.com>
Move code related to VirtIO RNG configuration for a VM to its own
module.
Also remove mentions about entropy-starvation when using /dev/random as
the entropy source from the descriptions of the rng parameters. This
concern no longer applies since the removal of the blocking entropy pool
in kernel version 5.6. [1] [2]
[1] https://git.kernel.org/torvalds/c/acd77500aa8a337baa6d853568c4b55aca48e20f
[2] https://lwn.net/Articles/808575/
Signed-off-by: Filip Schauer <f.schauer@proxmox.com>
---
PVE/QemuServer.pm | 63 +-----------------------------
PVE/QemuServer/Makefile | 1 +
PVE/QemuServer/RNG.pm | 86 +++++++++++++++++++++++++++++++++++++++++
3 files changed, 89 insertions(+), 61 deletions(-)
create mode 100644 PVE/QemuServer/RNG.pm
diff --git a/PVE/QemuServer.pm b/PVE/QemuServer.pm
index 808c0e1c..09d2b3a8 100644
--- a/PVE/QemuServer.pm
+++ b/PVE/QemuServer.pm
@@ -60,6 +60,7 @@ use PVE::QemuServer::MetaInfo;
use PVE::QemuServer::Monitor qw(mon_cmd);
use PVE::QemuServer::PCI qw(print_pci_addr print_pcie_addr print_pcie_root_port parse_hostpci);
use PVE::QemuServer::QMPHelpers qw(qemu_deviceadd qemu_devicedel qemu_objectadd qemu_objectdel);
+use PVE::QemuServer::RNG qw(check_rng_source parse_rng);
use PVE::QemuServer::USB;
my $have_sdn;
@@ -248,39 +249,6 @@ my $spice_enhancements_fmt = {
},
};
-my $rng_fmt = {
- source => {
- type => 'string',
- enum => ['/dev/urandom', '/dev/random', '/dev/hwrng'],
- default_key => 1,
- description => "The file on the host to gather entropy from. In most cases '/dev/urandom'"
- ." should be preferred over '/dev/random' to avoid entropy-starvation issues on the"
- ." host. Using urandom does *not* decrease security in any meaningful way, as it's"
- ." still seeded from real entropy, and the bytes provided will most likely be mixed"
- ." with real entropy on the guest as well. '/dev/hwrng' can be used to pass through"
- ." a hardware RNG from the host.",
- },
- max_bytes => {
- type => 'integer',
- description => "Maximum bytes of entropy allowed to get injected into the guest every"
- ." 'period' milliseconds. Prefer a lower value when using '/dev/random' as source. Use"
- ." `0` to disable limiting (potentially dangerous!).",
- optional => 1,
-
- # default is 1 KiB/s, provides enough entropy to the guest to avoid boot-starvation issues
- # (e.g. systemd etc...) while allowing no chance of overwhelming the host, provided we're
- # reading from /dev/urandom
- default => 1024,
- },
- period => {
- type => 'integer',
- description => "Every 'period' milliseconds the entropy-injection quota is reset, allowing"
- ." the guest to retrieve another 'max_bytes' of entropy.",
- optional => 1,
- default => 1000,
- },
-};
-
my $confdesc = {
onboot => {
optional => 1,
@@ -708,7 +676,7 @@ EODESCR
},
rng0 => {
type => 'string',
- format => $rng_fmt,
+ format => 'pve-qm-rng',
description => "Configure a VirtIO-based Random Number Generator.",
optional => 1,
},
@@ -1971,16 +1939,6 @@ sub parse_vga {
return $res;
}
-sub parse_rng {
- my ($value) = @_;
-
- return if !$value;
-
- my $res = eval { parse_property_string($rng_fmt, $value) };
- warn $@ if $@;
- return $res;
-}
-
sub qemu_created_version_fixups {
my ($conf, $forcemachine, $kvmver) = @_;
@@ -4020,23 +3978,6 @@ sub config_to_command {
return wantarray ? ($cmd, $vollist, $spice_port, $pci_devices) : $cmd;
}
-sub check_rng_source {
- my ($source) = @_;
-
- # mostly relevant for /dev/hwrng, but doesn't hurt to check others too
- die "cannot create VirtIO RNG device: source file '$source' doesn't exist\n"
- if ! -e $source;
-
- my $rng_current = '/sys/devices/virtual/misc/hw_random/rng_current';
- if ($source eq '/dev/hwrng' && file_read_firstline($rng_current) eq 'none') {
- # Needs to abort, otherwise QEMU crashes on first rng access. Note that rng_current cannot
- # be changed to 'none' manually, so once the VM is past this point, it's no longer an issue.
- die "Cannot start VM with passed-through RNG device: '/dev/hwrng' exists, but"
- ." '$rng_current' is set to 'none'. Ensure that a compatible hardware-RNG is attached"
- ." to the host.\n";
- }
-}
-
sub spice_port {
my ($vmid) = @_;
diff --git a/PVE/QemuServer/Makefile b/PVE/QemuServer/Makefile
index 18fd13ea..83c6af79 100644
--- a/PVE/QemuServer/Makefile
+++ b/PVE/QemuServer/Makefile
@@ -1,4 +1,5 @@
SOURCES=PCI.pm \
+ RNG.pm \
USB.pm \
Memory.pm \
ImportDisk.pm \
diff --git a/PVE/QemuServer/RNG.pm b/PVE/QemuServer/RNG.pm
new file mode 100644
index 00000000..22d1e9cc
--- /dev/null
+++ b/PVE/QemuServer/RNG.pm
@@ -0,0 +1,86 @@
+package PVE::QemuServer::RNG;
+
+use strict;
+use warnings;
+
+use PVE::JSONSchema;
+use PVE::Tools qw(file_read_firstline);
+
+use PVE::QemuServer::PCI qw(print_pci_addr);
+
+use base 'Exporter';
+
+our @EXPORT_OK = qw(
+parse_rng
+check_rng_source
+);
+
+my $rng_fmt = {
+ source => {
+ type => 'string',
+ enum => ['/dev/urandom', '/dev/random', '/dev/hwrng'],
+ default_key => 1,
+ description => "The file on the host to gather entropy from. Using urandom does *not*"
+ ." decrease security in any meaningful way, as it's still seeded from real entropy, and"
+ ." the bytes provided will most likely be mixed with real entropy on the guest as well."
+ ." '/dev/hwrng' can be used to pass through a hardware RNG from the host.",
+ },
+ max_bytes => {
+ type => 'integer',
+ description => "Maximum bytes of entropy allowed to get injected into the guest every"
+ ." 'period' milliseconds. Use `0` to disable limiting (potentially dangerous!).",
+ optional => 1,
+
+ # default is 1 KiB/s, provides enough entropy to the guest to avoid boot-starvation issues
+ # (e.g. systemd etc...) while allowing no chance of overwhelming the host, provided we're
+ # reading from /dev/urandom
+ default => 1024,
+ },
+ period => {
+ type => 'integer',
+ description => "Every 'period' milliseconds the entropy-injection quota is reset, allowing"
+ ." the guest to retrieve another 'max_bytes' of entropy.",
+ optional => 1,
+ default => 1000,
+ },
+};
+
+PVE::JSONSchema::register_format('pve-qm-rng', $rng_fmt);
+
+our $rngdesc = {
+ type => 'string',
+ format => $rng_fmt,
+ optional => 1,
+ description => "Configure a VirtIO-based Random Number Generator.",
+};
+PVE::JSONSchema::register_standard_option('pve-qm-rng', $rngdesc);
+
+sub parse_rng {
+ my ($value) = @_;
+
+ return if !$value;
+
+ my $res = eval { PVE::JSONSchema::parse_property_string($rng_fmt, $value) };
+ warn $@ if $@;
+
+ return $res;
+}
+
+sub check_rng_source {
+ my ($source) = @_;
+
+ # mostly relevant for /dev/hwrng, but doesn't hurt to check others too
+ die "cannot create VirtIO RNG device: source file '$source' doesn't exist\n"
+ if ! -e $source;
+
+ my $rng_current = '/sys/devices/virtual/misc/hw_random/rng_current';
+ if ($source eq '/dev/hwrng' && file_read_firstline($rng_current) eq 'none') {
+ # Needs to abort, otherwise QEMU crashes on first rng access. Note that rng_current cannot
+ # be changed to 'none' manually, so once the VM is past this point, it's no longer an issue.
+ die "Cannot start VM with passed-through RNG device: '/dev/hwrng' exists, but"
+ ." '$rng_current' is set to 'none'. Ensure that a compatible hardware-RNG is attached"
+ ." to the host.\n";
+ }
+}
+
+1;
--
2.39.5
_______________________________________________
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
next prev parent reply other threads:[~2025-02-10 15:38 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-02-10 15:37 [pve-devel] [PATCH cluster/guest-common/manager/qemu-server v3 00/11] fix #5657: allow configuring RNG device as non-root user Filip Schauer
2025-02-10 15:37 ` [pve-devel] [PATCH guest-common v3 01/11] mapping: add a hardware RNG mapping config Filip Schauer
2025-02-10 15:37 ` [pve-devel] [PATCH cluster v3 02/11] cfs: add 'mapping/hwrng.cfg' to observed files Filip Schauer
2025-02-10 15:37 ` [pve-devel] [PATCH manager v3 03/11] introduce hardware rng mapping api Filip Schauer
2025-02-10 15:37 ` [pve-devel] [PATCH manager v3 04/11] introduce hardware rng scanning api Filip Schauer
2025-02-10 15:37 ` [pve-devel] [PATCH manager v3 05/11] ui: add hardware RNG resource mapping Filip Schauer
2025-02-10 15:37 ` [pve-devel] [PATCH manager v3 06/11] ui: allow use of mapped hardware RNGs as entropy sources for VMs Filip Schauer
2025-02-10 15:37 ` [pve-devel] [PATCH manager v3 07/11] ui: split resource mapping types into tabbed views Filip Schauer
2025-02-10 15:37 ` Filip Schauer [this message]
2025-02-10 15:37 ` [pve-devel] [PATCH qemu-server v3 09/11] add helpers for VirtIO RNG command line arguments Filip Schauer
2025-02-10 15:37 ` [pve-devel] [PATCH qemu-server v3 10/11] allow non-root users to set /dev/u?random as an RNG source Filip Schauer
2025-02-11 12:34 ` Fabian Grünbichler
2025-02-10 15:37 ` [pve-devel] [PATCH qemu-server v3 11/11] let VirtIO RNG devices source entropy from mapped HWRNGs Filip Schauer
2025-02-11 12:34 ` Fabian Grünbichler
2025-02-11 12:34 ` [pve-devel] [PATCH cluster/guest-common/manager/qemu-server v3 00/11] fix #5657: allow configuring RNG device as non-root user Fabian Grünbichler
2025-02-18 11:17 ` Filip Schauer
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20250210153734.103381-9-f.schauer@proxmox.com \
--to=f.schauer@proxmox.com \
--cc=pve-devel@lists.proxmox.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.