On Tue, Apr 11, 2023 at 6:19 PM Amit Shah <a...@infradead.org> wrote: > > Hey Babis, > > On Mon, 2023-04-03 at 12:52 +0200, Babis Chalios wrote: > > This patchset implements the entropy leak reporting feature proposal [1] > > for virtio-rng devices. > > > > Entropy leaking (as defined in the specification proposal) typically > > happens when we take a snapshot of a VM or while we resume a VM from a > > snapshot. In these cases, we want to let the guest know so that it can > > reset state that needs to be uniqueue, for example. > > > > This feature is offering functionality similar to what VMGENID does. > > However, it allows to build mechanisms on the guest side to notify > > user-space applications, like VMGENID for userspace and additionally for > > kernel. > > > > The new specification describes two request types that the guest might > > place in the queues for the device to perform, a fill-on-leak request > > where the device needs to fill with random bytes a buffer and a > > copy-on-leak request where the device needs to perform a copy between > > two guest-provided buffers. We currently trigger the handling of guest > > requests when saving the VM state and when loading a VM from a snapshot > > file. > > > > This is an RFC, since the corresponding specification changes have not > > yet been merged. It also aims to allow testing a respective patch-set > > implementing the feature in the Linux front-end driver[2]. > > > > However, I would like to ask the community's opinion regarding the > > handling of the fill-on-leak requests. Essentially, these requests are > > very similar to the normal virtio-rng entropy requests, with the catch > > that we should complete these requests before resuming the VM, so that > > we avoid race-conditions in notifying the guest about entropy leak > > events. This means that we cannot rely on the RngBackend's API, which is > > asynchronous. At the moment, I have handled that using getrandom(), but > > I would like a solution which doesn't work only with (relatively new) > > Linux hosts. I am inclined to solve that by extending the RngBackend API > > with a synchronous call to request for random bytes and I'd like to hear > > opinion's on this approach. > > The patch looks OK - I suggest you add a new sync call that also probes > for the availability of getrandom().
qemu_guest_getrandom_nofail?
