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

[Babis Chalios <bchalios@amazon.es>]

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 <mst@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-bchalios@amazon.es/T/