[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [virtio-dev] [PATCH RFC 3/3] rng: leak detection support
On Wed, Sep 13, 2023 at 01:19:49PM +0200, Babis Chalios wrote: > > > 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. driver can just pre-add buffers in the second queue. 1. available buffers to queue 1-X 2. available buffers to queue X 3. poll queue X 4. used buffers in queue X 5. avail buffers in queue X 6. poll queue 1-X 7. used buffers in queue X 8. avail buffers in queue X 9. goto 3 > > -- > > 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]