From: "Michael S. Tsirkin" <mst@redhat.com>
To: Adrian Catangiu <acatan@amazon.com>
Cc: linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org,
qemu-devel@nongnu.org, kvm@vger.kernel.org,
linux-s390@vger.kernel.org, gregkh@linuxfoundation.org,
graf@amazon.com, arnd@arndb.de, ebiederm@xmission.com,
rppt@kernel.org, 0x7f454c46@gmail.com, borntraeger@de.ibm.com,
Jason@zx2c4.com, jannh@google.com, w@1wt.eu, colmmacc@amazon.com,
luto@kernel.org, tytso@mit.edu, ebiggers@kernel.org,
dwmw@amazon.co.uk, bonzini@gnu.org, sblbir@amazon.com,
raduweis@amazon.com, corbet@lwn.net, mhocko@kernel.org,
rafael@kernel.org, pavel@ucw.cz, mpe@ellerman.id.au,
areber@redhat.com, ovzxemul@gmail.com, avagin@gmail.com,
ptikhomirov@virtuozzo.com, gil@azul.com, asmehra@redhat.com,
dgunigun@redhat.com, vijaysun@ca.ibm.com, oridgar@gmail.com,
ghammer@redhat.com
Subject: Re: [PATCH v4 0/2] System Generation ID driver and VMGENID backend
Date: Tue, 12 Jan 2021 07:48:27 -0500 [thread overview]
Message-ID: <20210112074658-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <1610453760-13812-1-git-send-email-acatan@amazon.com>
On Tue, Jan 12, 2021 at 02:15:58PM +0200, Adrian Catangiu wrote:
> This feature is aimed at virtualized or containerized environments
> where VM or container snapshotting duplicates memory state, which is a
> challenge for applications that want to generate unique data such as
> request IDs, UUIDs, and cryptographic nonces.
>
> The patch set introduces a mechanism that provides a userspace
> interface for applications and libraries to be made aware of uniqueness
> breaking events such as VM or container snapshotting, and allow them to
> react and adapt to such events.
>
> Solving the uniqueness problem strongly enough for cryptographic
> purposes requires a mechanism which can deterministically reseed
> userspace PRNGs with new entropy at restore time. This mechanism must
> also support the high-throughput and low-latency use-cases that led
> programmers to pick a userspace PRNG in the first place; be usable by
> both application code and libraries; allow transparent retrofitting
> behind existing popular PRNG interfaces without changing application
> code; it must be efficient, especially on snapshot restore; and be
> simple enough for wide adoption.
>
> The first patch in the set implements a device driver which exposes a
> read-only device /dev/sysgenid to userspace, which contains a
> monotonically increasing u32 generation counter. Libraries and
> applications are expected to open() the device, and then call read()
> which blocks until the SysGenId changes. Following an update, read()
> calls no longer block until the application acknowledges the new
> SysGenId by write()ing it back to the device. Non-blocking read() calls
> return EAGAIN when there is no new SysGenId available. Alternatively,
> libraries can mmap() the device to get a single shared page which
> contains the latest SysGenId at offset 0.
Looking at some specifications, the gen ID might actually be located
at an arbitrary address. How about instead of hard-coding the offset,
we expose it e.g. in sysfs?
> SysGenId also supports a notification mechanism exposed as two IOCTLs
> on the device. SYSGENID_GET_OUTDATED_WATCHERS immediately returns the
> number of file descriptors to the device that were open during the last
> SysGenId change but have not yet acknowledged the new id.
> SYSGENID_WAIT_WATCHERS blocks until there are no open file handles on
> the device which haven’t acknowledged the new id. These two interfaces
> are intended for serverless and container control planes, which want to
> confirm that all application code has detected and reacted to the new
> SysGenId before sending an invoke to the newly-restored sandbox.
>
> The second patch in the set adds a VmGenId driver which makes use of
> the ACPI vmgenid device to drive SysGenId and to reseed kernel entropy
> on VM snapshots.
>
> ---
>
> v3 -> v4:
>
> - split functionality in two separate kernel modules:
> 1. drivers/misc/sysgenid.c which provides the generic userspace
> interface and mechanisms
> 2. drivers/virt/vmgenid.c as VMGENID acpi device driver that seeds
> kernel entropy and acts as a driving backend for the generic
> sysgenid
> - renamed /dev/vmgenid -> /dev/sysgenid
> - renamed uapi header file vmgenid.h -> sysgenid.h
> - renamed ioctls VMGENID_* -> SYSGENID_*
> - added ‘min_gen’ parameter to SYSGENID_FORCE_GEN_UPDATE ioctl
> - fixed races in documentation examples
> - various style nits
> - rebased on top of linus latest
>
> v2 -> v3:
>
> - separate the core driver logic and interface, from the ACPI device.
> The ACPI vmgenid device is now one possible backend.
> - fix issue when timeout=0 in VMGENID_WAIT_WATCHERS
> - add locking to avoid races between fs ops handlers and hw irq
> driven generation updates
> - change VMGENID_WAIT_WATCHERS ioctl so if the current caller is
> outdated or a generation change happens while waiting (thus making
> current caller outdated), the ioctl returns -EINTR to signal the
> user to handle event and retry. Fixes blocking on oneself.
> - add VMGENID_FORCE_GEN_UPDATE ioctl conditioned by
> CAP_CHECKPOINT_RESTORE capability, through which software can force
> generation bump.
>
> v1 -> v2:
>
> - expose to userspace a monotonically increasing u32 Vm Gen Counter
> instead of the hw VmGen UUID
> - since the hw/hypervisor-provided 128-bit UUID is not public
> anymore, add it to the kernel RNG as device randomness
> - insert driver page containing Vm Gen Counter in the user vma in
> the driver's mmap handler instead of using a fault handler
> - turn driver into a misc device driver to auto-create /dev/vmgenid
> - change ioctl arg to avoid leaking kernel structs to userspace
> - update documentation
> - various nits
> - rebase on top of linus latest
>
> Adrian Catangiu (2):
> drivers/misc: sysgenid: add system generation id driver
> drivers/virt: vmgenid: add vm generation id driver
>
> Documentation/misc-devices/sysgenid.rst | 240 +++++++++++++++++++++++++
> Documentation/virt/vmgenid.rst | 34 ++++
> drivers/misc/Kconfig | 16 ++
> drivers/misc/Makefile | 1 +
> drivers/misc/sysgenid.c | 298 ++++++++++++++++++++++++++++++++
> drivers/virt/Kconfig | 14 ++
> drivers/virt/Makefile | 1 +
> drivers/virt/vmgenid.c | 153 ++++++++++++++++
> include/uapi/linux/sysgenid.h | 18 ++
> 9 files changed, 775 insertions(+)
> create mode 100644 Documentation/misc-devices/sysgenid.rst
> create mode 100644 Documentation/virt/vmgenid.rst
> create mode 100644 drivers/misc/sysgenid.c
> create mode 100644 drivers/virt/vmgenid.c
> create mode 100644 include/uapi/linux/sysgenid.h
>
> --
> 2.7.4
>
>
>
>
> Amazon Development Center (Romania) S.R.L. registered office: 27A Sf. Lazar Street, UBC5, floor 2, Iasi, Iasi County, 700045, Romania. Registered in Romania. Registration number J22/2621/2005.
next prev parent reply other threads:[~2021-01-12 12:52 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-01-12 12:15 [PATCH v4 0/2] System Generation ID driver and VMGENID backend Adrian Catangiu
2021-01-12 12:15 ` [PATCH v4 1/2] drivers/misc: sysgenid: add system generation id driver Adrian Catangiu
2021-01-12 13:08 ` Greg KH
2021-01-21 9:54 ` Catangiu, Adrian Costin
2021-01-12 13:08 ` Michael S. Tsirkin
2021-01-21 12:48 ` Catangiu, Adrian Costin
2021-01-19 22:34 ` Randy Dunlap
2021-01-27 22:15 ` Pavel Machek
2021-02-02 14:32 ` Michael S. Tsirkin
2021-01-12 12:16 ` [PATCH v4 2/2] drivers/virt: vmgenid: add vm " Adrian Catangiu
2021-01-12 12:48 ` Michael S. Tsirkin [this message]
2021-01-21 10:28 ` [PATCH v4 0/2] System Generation ID driver and VMGENID backend Catangiu, Adrian Costin
2021-01-27 12:47 ` Michael S. Tsirkin
2021-01-28 12:58 ` Alexander Graf
2021-02-02 14:34 ` Michael S. Tsirkin
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=20210112074658-mutt-send-email-mst@kernel.org \
--to=mst@redhat.com \
--cc=0x7f454c46@gmail.com \
--cc=Jason@zx2c4.com \
--cc=acatan@amazon.com \
--cc=areber@redhat.com \
--cc=arnd@arndb.de \
--cc=asmehra@redhat.com \
--cc=avagin@gmail.com \
--cc=bonzini@gnu.org \
--cc=borntraeger@de.ibm.com \
--cc=colmmacc@amazon.com \
--cc=corbet@lwn.net \
--cc=dgunigun@redhat.com \
--cc=dwmw@amazon.co.uk \
--cc=ebiederm@xmission.com \
--cc=ebiggers@kernel.org \
--cc=ghammer@redhat.com \
--cc=gil@azul.com \
--cc=graf@amazon.com \
--cc=gregkh@linuxfoundation.org \
--cc=jannh@google.com \
--cc=kvm@vger.kernel.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-s390@vger.kernel.org \
--cc=luto@kernel.org \
--cc=mhocko@kernel.org \
--cc=mpe@ellerman.id.au \
--cc=oridgar@gmail.com \
--cc=ovzxemul@gmail.com \
--cc=pavel@ucw.cz \
--cc=ptikhomirov@virtuozzo.com \
--cc=qemu-devel@nongnu.org \
--cc=raduweis@amazon.com \
--cc=rafael@kernel.org \
--cc=rppt@kernel.org \
--cc=sblbir@amazon.com \
--cc=tytso@mit.edu \
--cc=vijaysun@ca.ibm.com \
--cc=w@1wt.eu \
/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;
as well as URLs for NNTP newsgroup(s).