Yes, that's what the driver does now in the RFC patch. However, this just
decreases
the race window, it doesn't eliminate it. If a third leak event happens it
might not
find any buffers to use:
1. available buffers to queue 1-X
2. available buffers to queue X
3. poll queue X
4. used buffers in queue X <- leak event 1 will use buffers in X
5. avail buffers in queue X
6. poll queue 1-X <- leak event 2 will use buffers in 1-X
7. used buffers in queue 1-X
8. avail buffers in queue 1-X
<- leak event 3 (it needs buffers in X, race
with step 5)
9. goto 3
I don't get it. we added buffers in step 5.
What if the leak event 3 arrives before step 5 had time to actually add the
buffers in X and make
them visible to the device?
Then it will see a single event in 1-X instead of two events. A leak is
a leak though, I don't see does it matter how many triggered.
So the scenario I have in mind is the following:
(Epoch here is terminology that I used in the Linux RFC).
Driver
Device
1. add buffers to 1-X
2. add buffers to X
3. poll queue X
4. vcpu 0: cache getrandom() entropy
and cache epoch value
5. First snapshot: use buffers in X
6. vcpu 1: sees used buffers
7. Second snapshot: use buffers in 1-X
8. vcpu 0: getrandom() observes new
epoch value & caches it
9. Third snapshot: no buffers in either queue vcpu 1 (from
step 6 has not yet finished adding new buffers).
10. vcpu 1 adds new buffer in X
11. vcpu 0: getrandom() will not see new
epoch and gets stale entropy.
In this succession of events, when the third snapshot will happen, it
won't find any buffers in either queue,
so it won't increase the RNG epoch value. So, any entropy gathered after
step 8 will be the same across all
snapshots. Am I missing something?
Cheers,
Babis
---------------------------------------------------------------------
To unsubscribe, e-mail: virtio-dev-unsubscr...@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-h...@lists.oasis-open.org
