OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

virtio-dev message

[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


> 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


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]