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

[Amit Shah]

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().  If that doesn't exist, your new
code should figure out a way to deal with the lack of that call.

On older Linux or non-Linux, there are other ways of getting random
numbers, so I expect that sync backend you introduce get more capable.

                Amit