Re: [RFC PATCH 0/1] Implement entropy leak reporting for virtio-rng

[Amit Shah <amit@infradead.org>]

On Thu, 2023-04-13 at 15:36 +0200, Babis Chalios wrote:
> 
> On 11/4/23 18:20, Jason A. Donenfeld wrote:
> > CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.
> > 
> > 
> > 
> > On Tue, Apr 11, 2023 at 6:19 PM Amit Shah <amit@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?
> 
> That should work, I think. Any objections to this Amit?

That's one way to do it - and is fine too - but still needs probing
before calling in that function to ensure it's not going to fail.

		Amit