From: Andy Lutomirski <email@example.com> To: Jann Horn <firstname.lastname@example.org>, Mathieu Desnoyers <email@example.com> Cc: Jason Donenfeld <Jason@zx2c4.com>, KVM list <firstname.lastname@example.org>, "email@example.com" <firstname.lastname@example.org>, "email@example.com" <firstname.lastname@example.org>, "Weiss, Radu" <email@example.com>, "firstname.lastname@example.org" <email@example.com>, "firstname.lastname@example.org" <email@example.com>, Pavel Machek <firstname.lastname@example.org>, "email@example.com" <firstname.lastname@example.org>, "email@example.com" <firstname.lastname@example.org>, Eric Biggers <email@example.com>, "Singh, Balbir" <firstname.lastname@example.org>, "email@example.com" <firstname.lastname@example.org>, "Graf \(AWS\), Alexander" <email@example.com>, Michal Hocko <firstname.lastname@example.org>, "email@example.com" <firstname.lastname@example.org>, "Catangiu, Adrian Costin" <email@example.com>, Andy Lutomirski <firstname.lastname@example.org>, "MacCarthaigh, Colm" <email@example.com>, "Theodore Y. Ts'o" <firstname.lastname@example.org>, "email@example.com" <firstname.lastname@example.org>, "email@example.com" <firstname.lastname@example.org>, Linux API <email@example.com>, "Rafael J. Wysocki" <firstname.lastname@example.org>, Willy Tarreau <email@example.com>, "Woodhouse, David" <firstname.lastname@example.org> Subject: Re: [PATCH] drivers/virt: vmgenid: add vm generation id driver Date: Sat, 17 Oct 2020 11:10:26 -0700 Message-ID: <CALCETrViTg_BWvRa+nfDWq=_B_ithzL-anVJNpsgHaXe9VgCNQ@mail.gmail.com> (raw) In-Reply-To: <CAG48ez0EanBvDyfthe+hAP0OC8iGLNSq2e5wJVz-=ENNGF97_w@mail.gmail.com> On Fri, Oct 16, 2020 at 6:40 PM Jann Horn <email@example.com> wrote: > > [adding some more people who are interested in RNG stuff: Andy, Jason, > Theodore, Willy Tarreau, Eric Biggers. also linux-api@, because this > concerns some pretty fundamental API stuff related to RNG usage] > > On Fri, Oct 16, 2020 at 4:33 PM Catangiu, Adrian Costin > <firstname.lastname@example.org> wrote: > > - Background > > > > The VM Generation ID is a feature defined by Microsoft (paper: > > http://go.microsoft.com/fwlink/?LinkId=260709) and supported by > > multiple hypervisor vendors. > > > > The feature is required in virtualized environments by apps that work > > with local copies/caches of world-unique data such as random values, > > uuids, monotonically increasing counters, etc. > > Such apps can be negatively affected by VM snapshotting when the VM > > is either cloned or returned to an earlier point in time. > > > > The VM Generation ID is a simple concept meant to alleviate the issue > > by providing a unique ID that changes each time the VM is restored > > from a snapshot. The hw provided UUID value can be used to > > differentiate between VMs or different generations of the same VM. > > > > - Problem > > > > The VM Generation ID is exposed through an ACPI device by multiple > > hypervisor vendors but neither the vendors or upstream Linux have no > > default driver for it leaving users to fend for themselves. > > > > Furthermore, simply finding out about a VM generation change is only > > the starting point of a process to renew internal states of possibly > > multiple applications across the system. This process could benefit > > from a driver that provides an interface through which orchestration > > can be easily done. > > > > - Solution > > > > This patch is a driver which exposes the Virtual Machine Generation ID > > via a char-dev FS interface that provides ID update sync and async > > notification, retrieval and confirmation mechanisms: > > > > When the device is 'open()'ed a copy of the current vm UUID is > > associated with the file handle. 'read()' operations block until the > > associated UUID is no longer up to date - until HW vm gen id changes - > > at which point the new UUID is provided/returned. Nonblocking 'read()' > > uses EWOULDBLOCK to signal that there is no _new_ UUID available. > > > > 'poll()' is implemented to allow polling for UUID updates. Such > > updates result in 'EPOLLIN' events. > > > > Subsequent read()s following a UUID update no longer block, but return > > the updated UUID. The application needs to acknowledge the UUID update > > by confirming it through a 'write()'. > > Only on writing back to the driver the right/latest UUID, will the > > driver mark this "watcher" as up to date and remove EPOLLIN status. > > > > 'mmap()' support allows mapping a single read-only shared page which > > will always contain the latest UUID value at offset 0. > > It would be nicer if that page just contained an incrementing counter, > instead of a UUID. It's not like the application cares *what* the UUID > changed to, just that it *did* change and all RNGs state now needs to > be reseeded from the kernel, right? And an application can't reliably > read the entire UUID from the memory mapping anyway, because the VM > might be forked in the middle. > > So I think your kernel driver should detect UUID changes and then turn > those into a monotonically incrementing counter. (Probably 64 bits > wide?) (That's probably also a little bit faster than comparing an > entire UUID.) > > An option might be to put that counter into the vDSO, instead of a > separate VMA; but I don't know how the other folks feel about that. > Andy, do you have opinions on this? That way, normal userspace code > that uses this infrastructure wouldn't have to mess around with a > special device at all. And it'd be usable in seccomp sandboxes and so > on without needing special plumbing. And libraries wouldn't have to > call open() and mess with file descriptor numbers. The vDSO might be annoyingly slow for this. Something like the rseq page might make sense. It could be a generic indication of "system went through some form of suspend".
next prev parent reply index Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top [not found] <AQHWo8lIfZnFKGe8nkGmhTCXwq5R3w==> 2020-10-16 14:33 ` Catangiu, Adrian Costin 2020-10-16 15:00 ` Catangiu, Adrian Costin 2020-10-16 15:14 ` gregkh 2020-10-17 1:40 ` Jann Horn 2020-10-17 3:36 ` Willy Tarreau 2020-10-17 4:02 ` Jann Horn 2020-10-17 4:34 ` Colm MacCarthaigh 2020-10-17 5:01 ` Jann Horn 2020-10-17 5:29 ` Colm MacCarthaigh 2020-10-17 5:37 ` Willy Tarreau 2020-10-17 5:52 ` Jann Horn 2020-10-17 6:44 ` Willy Tarreau 2020-10-17 6:55 ` Jann Horn 2020-10-17 7:17 ` Willy Tarreau 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-18 2:08 ` Jann Horn 2020-10-20 9:35 ` Christian Borntraeger 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 15:52 ` Michael S. Tsirkin 2020-10-18 15:54 ` Andy Lutomirski 2020-10-18 15:59 ` Michael S. Tsirkin 2020-10-18 16:14 ` Andy Lutomirski 2020-10-19 15:00 ` Michael S. Tsirkin 2020-10-17 18:10 ` Andy Lutomirski [this message] 2020-10-19 17:15 ` Mathieu Desnoyers 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='CALCETrViTg_BWvRa+nfDWq=_B_ithzL-anVJNpsgHaXe9VgCNQ@mail.gmail.com' \ --email@example.com \ --cc=Jason@zx2c4.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.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
QEMU-Devel Archive on lore.kernel.org Archives are clonable: git clone --mirror https://lore.kernel.org/qemu-devel/0 qemu-devel/git/0.git git clone --mirror https://lore.kernel.org/qemu-devel/1 qemu-devel/git/1.git git clone --mirror https://lore.kernel.org/qemu-devel/2 qemu-devel/git/2.git # If you have public-inbox 1.1+ installed, you may # initialize and index your mirror using the following commands: public-inbox-init -V2 qemu-devel qemu-devel/ https://lore.kernel.org/qemu-devel \ firstname.lastname@example.org public-inbox-index qemu-devel Example config snippet for mirrors Newsgroup available over NNTP: nntp://nntp.lore.kernel.org/org.nongnu.qemu-devel AGPL code for this site: git clone https://public-inbox.org/public-inbox.git