[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 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 avoidtheissue by pre-populating both queues, but that does not solve the problem if a third entropy leakeventarrives. The probability of this happening is indeed small, but we thought of a potential solution tothis.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 thespec tojust 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 2If 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 andanother+ 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 allDoes it make sense? Cheers, Babisyes, 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]