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

 > 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

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]