From: Greg KH <gregkh@linuxfoundation.org>
To: "Jason A. Donenfeld" <Jason@zx2c4.com>
Cc: kvm@vger.kernel.org, linux-crypto@vger.kernel.org,
linux-hyperv@vger.kernel.org, linux-kernel@vger.kernel.org,
adrian@parity.io, ardb@kernel.org, ben@skyportsystems.com,
berrange@redhat.com, colmmacc@amazon.com, decui@microsoft.com,
dwmw@amazon.co.uk, ebiggers@kernel.org, ehabkost@redhat.com,
graf@amazon.com, haiyangz@microsoft.com, imammedo@redhat.com,
jannh@google.com, kys@microsoft.com, lersek@redhat.com,
linux@dominikbrodowski.net, mst@redhat.com,
qemu-devel@nongnu.org, raduweis@amazon.com,
sthemmin@microsoft.com, tytso@mit.edu, wei.liu@kernel.org
Subject: Re: [PATCH v4] virt: vmgenid: introduce driver for reinitializing RNG on VM fork
Date: Fri, 25 Feb 2022 13:52:45 +0100 [thread overview]
Message-ID: <YhjRHW0t/sxjb7Hi@kroah.com> (raw)
In-Reply-To: <20220225124848.909093-1-Jason@zx2c4.com>
On Fri, Feb 25, 2022 at 01:48:48PM +0100, Jason A. Donenfeld wrote:
> VM Generation ID is a feature from Microsoft, described at
> <https://go.microsoft.com/fwlink/?LinkId=260709>, and supported by
> Hyper-V and QEMU. Its usage is described in Microsoft's RNG whitepaper,
> <https://aka.ms/win10rng>, as:
>
> If the OS is running in a VM, there is a problem that most
> hypervisors can snapshot the state of the machine and later rewind
> the VM state to the saved state. This results in the machine running
> a second time with the exact same RNG state, which leads to serious
> security problems. To reduce the window of vulnerability, Windows
> 10 on a Hyper-V VM will detect when the VM state is reset, retrieve
> a unique (not random) value from the hypervisor, and reseed the root
> RNG with that unique value. This does not eliminate the
> vulnerability, but it greatly reduces the time during which the RNG
> system will produce the same outputs as it did during a previous
> instantiation of the same VM state.
>
> Linux has the same issue, and given that vmgenid is supported already by
> multiple hypervisors, we can implement more or less the same solution.
> So this commit wires up the vmgenid ACPI notification to the RNG's newly
> added add_vmfork_randomness() function.
>
> It can be used from qemu via the `-device vmgenid,guid=auto` parameter.
> After setting that, use `savevm` in the monitor to save the VM state,
> then quit QEMU, start it again, and use `loadvm`. That will trigger this
> driver's notify function, which hands the new UUID to the RNG. This is
> described in <https://git.qemu.org/?p=qemu.git;a=blob;f=docs/specs/vmgenid.txt>.
> And there are hooks for this in libvirt as well, described in
> <https://libvirt.org/formatdomain.html#general-metadata>.
>
> Note, however, that the treatment of this as a UUID is considered to be
> an accidental QEMU nuance, per
> <https://github.com/libguestfs/virt-v2v/blob/master/docs/vm-generation-id-across-hypervisors.txt>,
> so this driver simply treats these bytes as an opaque 128-bit binary
> blob, as per the spec. This doesn't really make a difference anyway,
> considering that's how it ends up when handed to the RNG in the end.
>
> Cc: Adrian Catangiu <adrian@parity.io>
> Cc: Daniel P. Berrangé <berrange@redhat.com>
> Cc: Dominik Brodowski <linux@dominikbrodowski.net>
> Cc: Ard Biesheuvel <ardb@kernel.org>
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
> Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
next prev parent reply other threads:[~2022-02-25 12:52 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-02-24 13:39 [PATCH v3 0/2] VM fork detection for RNG Jason A. Donenfeld
2022-02-24 13:39 ` [PATCH v3 1/2] random: add mechanism for VM forks to reinitialize crng Jason A. Donenfeld
2022-02-25 11:26 ` Ard Biesheuvel
2022-02-25 11:43 ` Jason A. Donenfeld
2022-02-25 11:44 ` Ard Biesheuvel
2022-02-24 13:39 ` [PATCH v3 2/2] virt: vmgenid: introduce driver for reinitializing RNG on VM fork Jason A. Donenfeld
2022-02-25 10:37 ` Laszlo Ersek
2022-02-25 11:24 ` Ard Biesheuvel
2022-02-25 11:51 ` Michael S. Tsirkin
2022-02-25 12:01 ` Jason A. Donenfeld
2022-02-25 12:00 ` Jason A. Donenfeld
2022-02-25 12:48 ` [PATCH v4] " Jason A. Donenfeld
2022-02-25 12:52 ` Greg KH [this message]
2022-02-25 12:53 ` Greg KH
2022-02-25 12:56 ` Jason A. Donenfeld
2022-02-25 15:04 ` Ard Biesheuvel
2022-02-25 13:57 ` Alexander Graf
2022-02-25 14:12 ` Jason A. Donenfeld
2022-02-25 14:18 ` Jason A. Donenfeld
2022-02-25 14:18 ` Alexander Graf
2022-02-25 14:33 ` Jason A. Donenfeld
2022-02-25 15:11 ` Alexander Graf
2022-02-25 15:16 ` Ard Biesheuvel
2022-02-25 15:22 ` Alexander Graf
2022-02-25 15:43 ` Jason A. Donenfeld
2022-02-25 15:57 ` Alexander Graf
2022-02-25 15:34 ` Jason A. Donenfeld
2022-02-25 15:37 ` Alexander Graf
2022-02-25 15:45 ` Jason A. Donenfeld
2022-02-25 14:36 ` Greg KH
2022-02-25 15:31 ` Alexander Graf
2022-02-25 15:36 ` Jason A. Donenfeld
2022-02-25 14:54 ` Jason A. Donenfeld
2022-02-25 15:15 ` Alexander Graf
2022-02-25 15:28 ` Jason A. Donenfeld
2022-02-25 15:03 ` Ard Biesheuvel
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=YhjRHW0t/sxjb7Hi@kroah.com \
--to=gregkh@linuxfoundation.org \
--cc=Jason@zx2c4.com \
--cc=adrian@parity.io \
--cc=ardb@kernel.org \
--cc=ben@skyportsystems.com \
--cc=berrange@redhat.com \
--cc=colmmacc@amazon.com \
--cc=decui@microsoft.com \
--cc=dwmw@amazon.co.uk \
--cc=ebiggers@kernel.org \
--cc=ehabkost@redhat.com \
--cc=graf@amazon.com \
--cc=haiyangz@microsoft.com \
--cc=imammedo@redhat.com \
--cc=jannh@google.com \
--cc=kvm@vger.kernel.org \
--cc=kys@microsoft.com \
--cc=lersek@redhat.com \
--cc=linux-crypto@vger.kernel.org \
--cc=linux-hyperv@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@dominikbrodowski.net \
--cc=mst@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=raduweis@amazon.com \
--cc=sthemmin@microsoft.com \
--cc=tytso@mit.edu \
--cc=wei.liu@kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox