From: Willy Tarreau <w@1wt.eu>
To: Jann Horn <jannh@google.com>
Cc: Colm MacCarthaigh <colmmacc@amazon.com>,
"Catangiu, Adrian Costin" <acatan@amazon.com>,
Andy Lutomirski <luto@kernel.org>,
Jason Donenfeld <Jason@zx2c4.com>,
"Theodore Y. Ts'o" <tytso@mit.edu>,
Eric Biggers <ebiggers@kernel.org>,
"open list:DOCUMENTATION" <linux-doc@vger.kernel.org>,
kernel list <linux-kernel@vger.kernel.org>,
"open list:VIRTIO GPU DRIVER"
<virtualization@lists.linux-foundation.org>, "Graf (AWS),
Alexander" <graf@amazon.de>,
"Woodhouse, David" <dwmw@amazon.co.uk>,
bonzini@gnu.org, "Singh, Balbir" <sblbir@amazon.com>,
"Weiss, Radu" <raduweis@amazon.com>,
oridgar@gmail.com, ghammer@redhat.com,
Jonathan Corbet <corbet@lwn.net>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
"Michael S. Tsirkin" <mst@redhat.com>,
Qemu Developers <qemu-devel@nongnu.org>,
KVM list <kvm@vger.kernel.org>, Michal Hocko <mhocko@kernel.org>,
"Rafael J. Wysocki" <rafael@kernel.org>,
Pavel Machek <pavel@ucw.cz>,
Linux API <linux-api@vger.kernel.org>
Subject: Re: [PATCH] drivers/virt: vmgenid: add vm generation id driver
Date: Sat, 17 Oct 2020 09:17:21 +0200 [thread overview]
Message-ID: <20201017071721.GA14143@1wt.eu> (raw)
In-Reply-To: <CAG48ez3pXLC+eqAXDCniM0a+5yP2XJODDkZqiUTZUOttCE_LbA@mail.gmail.com>
On Sat, Oct 17, 2020 at 08:55:34AM +0200, Jann Horn wrote:
> My suggestion is to use a counter *in the UAPI*, not in the hypervisor
> protocol. (And as long as that counter can only miss increments in a
> cryptographically negligible fraction of cases, everything's fine.)
OK I got it now and I agree.
> > If what is sought is pure
> > randomness (in the sense that it's unpredictable, which I don't think
> > is needed here), then randoms are better.
>
> And this is what *the hypervisor protocol* gives us (which could be
> very useful for reseeding the kernel RNG).
As an external source, yes very likely, as long as it's not trivially
observable by everyone under the same hypervisor :-)
> > Now the initial needs in the forwarded message are not entirely clear
> > to me but I wanted to rule out the apparent mismatch between the expressed
> > needs for uniqueness and the proposed solutions solely based on randomness.
>
> Sure, from a theoretical standpoint, it would be a little bit nicer if
> the hypervisor protocol included a generation number along with the
> 128-bit random value. But AFAIU it doesn't, so if we want this to just
> work under Microsoft's existing hypervisor, we'll have to make do with
> checking whether the random value changed. :P
OK got it, thanks for the explanation!
Willy
WARNING: multiple messages have this Message-ID (diff)
From: Willy Tarreau <w@1wt.eu>
To: Jann Horn <jannh@google.com>
Cc: Jason Donenfeld <Jason@zx2c4.com>, KVM list <kvm@vger.kernel.org>,
"open list:DOCUMENTATION" <linux-doc@vger.kernel.org>,
ghammer@redhat.com, "Weiss, Radu" <raduweis@amazon.com>,
Qemu Developers <qemu-devel@nongnu.org>,
"open list:VIRTIO GPU DRIVER"
<virtualization@lists.linux-foundation.org>,
Pavel Machek <pavel@ucw.cz>,
Colm MacCarthaigh <colmmacc@amazon.com>,
Jonathan Corbet <corbet@lwn.net>,
"Michael S. Tsirkin" <mst@redhat.com>,
Eric Biggers <ebiggers@kernel.org>,
"Singh, Balbir" <sblbir@amazon.com>,
bonzini@gnu.org, "Graf \(AWS\), Alexander" <graf@amazon.de>,
oridgar@gmail.com, "Catangiu, Adrian Costin" <acatan@amazon.com>,
Andy Lutomirski <luto@kernel.org>,
Michal Hocko <mhocko@kernel.org>,
"Theodore Y. Ts'o" <tytso@mit.edu>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
kernel list <linux-kernel@vger.kernel.org>,
Linux API <linux-api@vger.kernel.org>,
"Rafael J. Wysocki" <rafael@kernel.org>,
"Woodhouse, David" <dwmw@amazon.co.uk>
Subject: Re: [PATCH] drivers/virt: vmgenid: add vm generation id driver
Date: Sat, 17 Oct 2020 09:17:21 +0200 [thread overview]
Message-ID: <20201017071721.GA14143@1wt.eu> (raw)
In-Reply-To: <CAG48ez3pXLC+eqAXDCniM0a+5yP2XJODDkZqiUTZUOttCE_LbA@mail.gmail.com>
On Sat, Oct 17, 2020 at 08:55:34AM +0200, Jann Horn wrote:
> My suggestion is to use a counter *in the UAPI*, not in the hypervisor
> protocol. (And as long as that counter can only miss increments in a
> cryptographically negligible fraction of cases, everything's fine.)
OK I got it now and I agree.
> > If what is sought is pure
> > randomness (in the sense that it's unpredictable, which I don't think
> > is needed here), then randoms are better.
>
> And this is what *the hypervisor protocol* gives us (which could be
> very useful for reseeding the kernel RNG).
As an external source, yes very likely, as long as it's not trivially
observable by everyone under the same hypervisor :-)
> > Now the initial needs in the forwarded message are not entirely clear
> > to me but I wanted to rule out the apparent mismatch between the expressed
> > needs for uniqueness and the proposed solutions solely based on randomness.
>
> Sure, from a theoretical standpoint, it would be a little bit nicer if
> the hypervisor protocol included a generation number along with the
> 128-bit random value. But AFAIU it doesn't, so if we want this to just
> work under Microsoft's existing hypervisor, we'll have to make do with
> checking whether the random value changed. :P
OK got it, thanks for the explanation!
Willy
next prev parent reply other threads:[~2020-10-17 7:18 UTC|newest]
Thread overview: 64+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <AQHWo8lIfZnFKGe8nkGmhTCXwq5R3w==>
2020-10-16 14:33 ` [PATCH] drivers/virt: vmgenid: add vm generation id driver Catangiu, Adrian Costin
2020-10-16 15:00 ` Catangiu, Adrian Costin
2020-10-16 15:14 ` gregkh
2020-10-16 15:14 ` gregkh
2020-10-16 15:14 ` gregkh
2020-10-17 1:40 ` Jann Horn
2020-10-17 1:40 ` Jann Horn via Virtualization
2020-10-17 3:36 ` Willy Tarreau
2020-10-17 3:36 ` Willy Tarreau
2020-10-17 4:02 ` Jann Horn
2020-10-17 4:02 ` Jann Horn via Virtualization
2020-10-17 4:34 ` Colm MacCarthaigh
2020-10-17 5:01 ` Jann Horn
2020-10-17 5:01 ` Jann Horn via Virtualization
2020-10-17 5:29 ` Colm MacCarthaigh
2020-10-17 5:29 ` Colm MacCarthaigh
2020-10-17 5:37 ` Willy Tarreau
2020-10-17 5:37 ` Willy Tarreau
2020-10-17 5:52 ` Jann Horn
2020-10-17 5:52 ` Jann Horn via Virtualization
2020-10-17 6:44 ` Willy Tarreau
2020-10-17 6:44 ` Willy Tarreau
2020-10-17 6:55 ` Jann Horn
2020-10-17 6:55 ` Jann Horn via Virtualization
2020-10-17 7:17 ` Willy Tarreau [this message]
2020-10-17 7:17 ` Willy Tarreau
2020-10-17 13:24 ` Jason A. Donenfeld
2020-10-17 13:24 ` Jason A. Donenfeld
2020-10-17 18:06 ` Catangiu, Adrian Costin
2020-10-17 18:09 ` Alexander Graf
2020-10-17 18:09 ` Alexander Graf
2020-10-18 2:08 ` Jann Horn
2020-10-18 2:08 ` Jann Horn via Virtualization
2020-10-20 9:35 ` Christian Borntraeger
2020-10-20 9:35 ` Christian Borntraeger
2020-10-20 9:35 ` Christian Borntraeger
2020-10-20 9:54 ` Alexander Graf
2020-10-20 9:54 ` Alexander Graf
2020-10-20 16:54 ` Catangiu, Adrian Costin
2020-10-18 3:14 ` Colm MacCarthaigh
2020-10-18 3:14 ` Colm MacCarthaigh
2020-10-18 15:52 ` Michael S. Tsirkin
2020-10-18 15:52 ` Michael S. Tsirkin
2020-10-18 15:52 ` Michael S. Tsirkin
2020-10-18 15:54 ` Andy Lutomirski
2020-10-18 15:54 ` Andy Lutomirski
2020-10-18 15:54 ` Andy Lutomirski
2020-10-18 15:59 ` Michael S. Tsirkin
2020-10-18 15:59 ` Michael S. Tsirkin
2020-10-18 15:59 ` Michael S. Tsirkin
2020-10-18 16:14 ` Andy Lutomirski
2020-10-18 16:14 ` Andy Lutomirski
2020-10-18 16:14 ` Andy Lutomirski
2020-10-19 15:00 ` Michael S. Tsirkin
2020-10-19 15:00 ` Michael S. Tsirkin
2020-10-19 15:00 ` Michael S. Tsirkin
2020-10-17 18:10 ` Andy Lutomirski
2020-10-17 18:10 ` Andy Lutomirski
2020-10-17 18:10 ` Andy Lutomirski
2020-10-19 17:15 ` Mathieu Desnoyers
2020-10-19 17:15 ` Mathieu Desnoyers
2020-10-19 17:15 ` Mathieu Desnoyers
2020-10-20 10:00 ` Alexander Graf
2020-10-20 10:00 ` Alexander Graf
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=20201017071721.GA14143@1wt.eu \
--to=w@1wt.eu \
--cc=Jason@zx2c4.com \
--cc=acatan@amazon.com \
--cc=bonzini@gnu.org \
--cc=colmmacc@amazon.com \
--cc=corbet@lwn.net \
--cc=dwmw@amazon.co.uk \
--cc=ebiggers@kernel.org \
--cc=ghammer@redhat.com \
--cc=graf@amazon.de \
--cc=gregkh@linuxfoundation.org \
--cc=jannh@google.com \
--cc=kvm@vger.kernel.org \
--cc=linux-api@vger.kernel.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@kernel.org \
--cc=mhocko@kernel.org \
--cc=mst@redhat.com \
--cc=oridgar@gmail.com \
--cc=pavel@ucw.cz \
--cc=qemu-devel@nongnu.org \
--cc=raduweis@amazon.com \
--cc=rafael@kernel.org \
--cc=sblbir@amazon.com \
--cc=tytso@mit.edu \
--cc=virtualization@lists.linux-foundation.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 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.