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 <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? > > 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