Hi Michael,
On 21/11/22 17:30, Michael S. Tsirkin wrote:
Add virtqueues to support reporting entropy leaks (similar to virtio based
vmgenid).
Signed-off-by: Michael S. Tsirkin <m...@redhat.com>
---
virtio-rng.tex | 61 +++++++++++++++++++++++++++++++++++++++++++++++++-
1 file changed, 60 insertions(+), 1 deletion(-)
diff --git a/virtio-rng.tex b/virtio-rng.tex
index 1ec7164..4760dfa 100644
--- a/virtio-rng.tex
+++ b/virtio-rng.tex
@@ -9,10 +9,14 @@ \subsection{Device ID}\label{sec:Device Types / Entropy
Device / Device ID}
\subsection{Virtqueues}\label{sec:Device Types / Entropy Device / Virtqueues}
\begin{description}
\item[0] requestq
+\item[1] leakq1 (only if VIRTIO_RNG_F_LEAK is offered)
+\item[2] leakq2 (only if VIRTIO_RNG_F_LEAK is offered)
\end{description}
\subsection{Feature bits}\label{sec:Device Types / Entropy Device / Feature bits}
- None currently defined
+\begin{description}
+\item[VIRTIO_RNG_F_LEAK (0)] Device can report and handle information leaks.
+\end{description}
\subsection{Device configuration layout}\label{sec:Device Types / Entropy Device / Device configuration layout}
None currently defined.
@@ -21,6 +25,7 @@ \subsection{Device Initialization}\label{sec:Device Types /
Entropy Device / Dev
\begin{enumerate}
\item The \field{requestq} virtqueue is initialized
+\item If VIRTIO_RNG_F_LEAK has been negotiated, \field{leakq1} and
\field{leakq2} are initialized
\end{enumerate}
\subsection{Device Operation}\label{sec:Device Types / Entropy Device / Device Operation}
@@ -41,3 +46,57 @@ \subsection{Device Operation}\label{sec:Device Types /
Entropy Device / Device O
The device MUST place one or more random bytes into the buffer
made available to it through \field{requestq}, but it
MAY use less than the entire buffer length.
+
+\subsubsection{Reporting Information Leaks}{Device Types / Entropy Device /
Device Operation / Reporting Information Leaks}
+
+The device might, after the fact, detect that some of the entropy
+it supplied to the driver has after the fact degraded in quality
+or leaked to the outside world. One example is when the device
+is part of the virtual machine undergoing a restore from snapshot
+operation. Another example is when the information leaks from the
+host system through a side-channel.
+
+The driver would typically react by causing regeneration of any
+information that might have leaked and that has to be secret or
+unique. It is understood that when an information leak has been
+detected it is likely not limited to the entropy received through
+the specific device. In particular, this is the case for
+snapshoting It is thus suggested that the system fully
+regenerate any unique/secret information in this scenario.
+
+If VIRTIO_RNG_F_LEAK has been negotiated the device can report
+such leaks to the driver through a set of dedicated leak
+queues: \field{leakq1} and \field{leakq2}.
+
+Buffers added to the leak queues can have one of two forms:
+\begin{enumerate}
+\item A write-only buffer. It will be completely filled by random data by the
device.
+\item A buffer consisting of read-only section followed by a
+write-only section, both of identical size. The
+device will copy data from the read-only section to the write-only
+section.
+\end{enumerate}
+
+The steps for operating the virtqueue are:
+
+\begin{enumerate}
+\item At each time, only one of \field{leakq1}, \field{leakq2} is active
+ (has buffers added/used).
+\item After initialization, \field{leakq1} is active.
+\item Driver adds multiple buffers to the active leak queue.
+\item The buffers are not used until an information leak is
+ detected, as long as that is the case driver can
+ add more buffers to the active queue.
+\item Upon detecting an information leak, device starts
+ using buffers in the active leak queue.
+\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.\
I have been discussing with Alex and we think there's a potential race
here, between the time the driver
sees the used buffers in the active leak queue until the time it adds
new buffers to the next leak queue.
If a new entropy leak event arrives the VMM won't find any buffers in
the queue.
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?
Cheers,
Babis
[1]
https://lore.kernel.org/lkml/20230823090107.65749-3-bchal...@amazon.es/T/
---------------------------------------------------------------------
To unsubscribe, e-mail: virtio-dev-unsubscr...@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-h...@lists.oasis-open.org