Re: [virtio-dev] [PATCH RFC 3/3] rng: leak detection support

[Babis Chalios <bchalios@amazon.es>]

On 13/9/23 11:37, Michael S. Tsirkin 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 Wed, Sep 13, 2023 at 11:32:57AM +0200, Babis Chalios wrote:
>>> I do not understand why this matters though. we know there was a leak,
>>> why does it matter whether there was one or two leaks?
>>>
>>>> In the last RFC implementing this in Linux we sent to LKML [1] we avoid
>> the
>>>> issue by pre-populating both
>>>> queues, but that does not solve the problem if a third entropy leak
>> event
>>>> arrives. The probability of this
>>>> happening is indeed small, but we thought of a potential solution to
>> this.
>>>> What if we modify the spec here to instruct the VMM to deny taking a
>>>> snapshot if there are not any buffers
>>>> in the active leak queue? If we did this, we could even simplify the
>> spec to
>>>> just introduce a single entropy
>>>> leak queue, so we could avoid the complexity of switching between active
>>>> leak queues in the driver and
>>>> the device. WDYT?
>>> here's the problem:
>>>
>>> - driver adds batch 1 of buffers
>>> - leak
>>> - device starts using buffers from batch 1
>>> - driver sees some buffers and starts adding batch 2
>> If understand this clause:
>>
>>>> +\item Upon detecting that buffers have been used, driver
>>>> +      switches to another leak queue making it active
>>>> +      (e.g. from \field{leakq1} to \field{leakq2} or vice versa).
>>>> +      It then starts adding buffers to the new leak queue.
>> correctly:
>>
>> At this point, the driver will first switch active leak queue and
>> then add batch 2 to the new leak queue.
>>
>> and due to this:
>>
>>>> +\item Device will keep using buffers in the active leak queue
>>>> +      until it detects that both the current leak queue is empty and
>> another
>>>> +      leak queue has buffers. At that point device switches to
>>>> +      another leak queue, making it active.
>>>> +\item After the switch, buffers from the new leak queue are not
>>>> +      used until an information leak is detected.
>>>> +\end{enumerate}
>> the following won't happen:
>>
>>> - device sees batch 2 and thinks this is part of batch 1
>>>      consumes them all
>> Does it make sense?
>>
>> Cheers,
>> Babis
> yes, the queue switch is used as a barrier to detect a new leak event.

Right, so I think that there is a race condition between the time the 
driver sees the used buffers of the first
batch and until it adds the second batch on the next leak queue.

1. driver adds batch 1
2. leak event
3. device uses batch 1
4. driver sees the used buffers and
     a. switches leak queues
     b. adds batch 2.
5. devices finds initial leak queue empty and sees buffers in second 
leak queue.

If a second leak event happens after step 3 above and before all of 
steps 4 complete then batch 2 will not
be processed as part of the second leak event.

> --
> MST
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
> For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org