[virtio-comment] [PATCH] Add virtio rpmb device specification

[virtio-comment] [PATCH] Add virtio rpmb device specification

[Huang Yang]

This is the virtio-rpmb specification draft, applied to the current
virtio-spec.
 
Below is a short description of RPMB and why we are doing this:
RPMB (Replay Protected Memory Block) is a physical partition in
eMMC, UFS or NVMe.
 
Different from the traditional user partition, RPMB requires
an RPMB authentication key and a monotonic write counter to access it.
Every access to RPMB is in an authenticated and replay protected manner.
 
RPMB access is authenticated by the Message Authentication Code (MAC),
which is a hash value generated based on RPMB authentication key
and the message using HMAC-SHA. The authentication key is programmed
in a secure environment before any access to RPMB. Writer counter is
the total number of successful authenticated data write on RPMB.
It is added by one automatically by RPMB controller after each
successful write operation. It is a required factor in messageto be
MACed together.
 
RPMB is widely used as a tamper-resistant and anti-replay storage.
For example, it’s used in these open source projects:
Google Trusty (https://source.android.com/security/trusty),
ACRN (https://projectacrn.org/),
OP-TEE (https://www.op-tee.org/) and so on.
 
But virtualization software like Qemu doesn't provide eMMC/UFS/NVMe
RPMB emulation. It blocks the OS like Trusty or OP-TEE running in a
virtualization environment. For instance, Google right now uses another
way to work around RPMB emulation issue when running Trusty in ARM Qemu:
https://android.googlesource.com/trusty/external/trusty/+/refs/heads/master/test-runner/

Virtio RPMB standardization will definitely benefit OP-TEE,
Google Trusty TEE, Qemu, OVMF or other modules to develop the RPMB
based secure storage in virtualization.
 
Virtio RPMB has been implemented in ACRN (https://projectacrn.org/).
Virtio RPMB device in ACRN devicemodel:
https://github.com/projectacrn/acrn-hypervisor/blob/master/devicemodel/hw/pci/virtio/virtio_rpmb.c
Virtio RPMB frontend driver in kernel:
https://github.com/projectacrn/acrn-kernel/blob/master/drivers/char/rpmb/virtio_rpmb.c


Huang Yang (1):
  Add virtio rpmb device specification

 conformance.tex | 18 +++++++++++-
 content.tex     |  3 ++
 virtio-rpmb.tex | 88 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 3 files changed, 108 insertions(+), 1 deletion(-)
 create mode 100644 virtio-rpmb.tex

-- 
2.7.4


This publicly archived list offers a means to provide input to the
OASIS Virtual I/O Device (VIRTIO) TC.

In order to verify user consent to the Feedback License terms and
to minimize spam in the list archive, subscription is required
before posting.

Subscribe: virtio-comment-subscribe@lists.oasis-open.org
Unsubscribe: virtio-comment-unsubscribe@lists.oasis-open.org
List help: virtio-comment-help@lists.oasis-open.org
List archive: https://lists.oasis-open.org/archives/virtio-comment/
Feedback License: https://www.oasis-open.org/who/ipr/feedback_license.pdf
List Guidelines: https://www.oasis-open.org/policies-guidelines/mailing-lists
Committee: https://www.oasis-open.org/committees/virtio/
Join OASIS: https://www.oasis-open.org/join/

[virtio-comment] [PATCH] Add virtio rpmb device specification

[Huang Yang]

It is a virtio based RPMB (Replay Protected Memory Block) device.

Signed-off-by: Yang Huang <yang.huang@intel.com>
Reviewed-by: Bing Zhu <bing.zhu@intel.com>
Reviewed-by: Tomas Winkler <tomas.winkler@intel.com> 

---
 conformance.tex | 18 +++++++++++-
 content.tex     |  3 ++
 virtio-rpmb.tex | 88 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 3 files changed, 108 insertions(+), 1 deletion(-)
 create mode 100644 virtio-rpmb.tex

diff --git a/conformance.tex b/conformance.tex
index 0ac58aa..07166ba 100644
--- a/conformance.tex
+++ b/conformance.tex
@@ -22,7 +22,7 @@ \section{Conformance Targets}\label{sec:Conformance / Conformance Targets}
   \begin{itemize}
     \item Clause \ref{sec:Conformance / Device Conformance}.
     \item One of clauses \ref{sec:Conformance / Device Conformance / PCI Device Conformance}, \ref{sec:Conformance / Device Conformance / MMIO Device Conformance} or \ref{sec:Conformance / Device Conformance / Channel I/O Device Conformance}.
-    \item One of clauses \ref{sec:Conformance / Device Conformance / Network Device Conformance}, \ref{sec:Conformance / Device Conformance / Block Device Conformance}, \ref{sec:Conformance / Device Conformance / Console Device Conformance}, \ref{sec:Conformance / Device Conformance / Entropy Device Conformance}, \ref{sec:Conformance / Device Conformance / Traditional Memory Balloon Device Conformance}, \ref{sec:Conformance / Device Conformance / SCSI Host Device Conformance}, \ref{sec:Conformance / Device Conformance / Input Device Conformance}, \ref{sec:Conformance / Device Conformance / Crypto Device Conformance} or \ref{sec:Conformance / Device Conformance / Socket Device Conformance}.
+    \item One of clauses \ref{sec:Conformance / Device Conformance / Network Device Conformance}, \ref{sec:Conformance / Device Conformance / Block Device Conformance}, \ref{sec:Conformance / Device Conformance / Console Device Conformance}, \ref{sec:Conformance / Device Conformance / Entropy Device Conformance}, \ref{sec:Conformance / Device Conformance / Traditional Memory Balloon Device Conformance}, \ref{sec:Conformance / Device Conformance / SCSI Host Device Conformance}, \ref{sec:Conformance / Device Conformance / Input Device Conformance}, \ref{sec:Conformance / Device Conformance / Crypto Device Conformance}, \ref{sec:Conformance / Device Conformance / Socket Device Conformance} or \ref{sec:Conformance / Device Conformance / RPMB Device Conformance}.
     \item Clause \ref{sec:Conformance / Legacy Interface: Transitional Device and Transitional Driver Conformance}.
   \end{itemize}
 \end{description}
@@ -183,6 +183,14 @@ \section{Conformance Targets}\label{sec:Conformance / Conformance Targets}
 \item \ref{drivernormative:Device Types / Socket Device / Device Operation / Device Events}
 \end{itemize}
 
+\conformance{\subsection}{RPMB Driver Conformance}\label{sec:Conformance / Driver Conformance / RPMB Driver Conformance}
+
+A RPMB driver MUST conform to the following normative statements:
+
+\begin{itemize}
+\item \ref{drivernormative:Device Types / RPMB Device / Device Operation}
+\end{itemize}
+
 \conformance{\section}{Device Conformance}\label{sec:Conformance / Device Conformance}
 
 A device MUST conform to the following normative statements:
@@ -338,6 +346,14 @@ \section{Conformance Targets}\label{sec:Conformance / Conformance Targets}
 \item \ref{devicenormative:Device Types / Socket Device / Device Operation / Receive and Transmit}
 \end{itemize}
 
+\conformance{\subsection}{RPMB Device Conformance}\label{sec:Conformance / Device Conformance / RPMB Device Conformance}
+
+An RPMB device MUST conform to the following normative statements:
+
+\begin{itemize}
+\item \ref{devicenormative:Device Types / RPMB Device / Device Operation}
+\end{itemize}
+
 \conformance{\section}{Legacy Interface: Transitional Device and Transitional Driver Conformance}\label{sec:Conformance / Legacy Interface: Transitional Device and Transitional Driver Conformance}
 A conformant implementation MUST be either transitional or
 non-transitional, see \ref{intro:Legacy
diff --git a/content.tex b/content.tex
index ee0d7c9..7f54f94 100644
--- a/content.tex
+++ b/content.tex
@@ -2717,6 +2717,8 @@ \chapter{Device Types}\label{sec:Device Types}
 \hline
 27         &   PMEM device \\
 \hline
+28         &   RPMB device \\
+\hline
 \end{tabular}
 
 Some of the devices above are unspecified by this document,
@@ -5677,6 +5679,7 @@ \subsubsection{Legacy Interface: Framing Requirements}\label{sec:Device
 \input{virtio-input.tex}
 \input{virtio-crypto.tex}
 \input{virtio-vsock.tex}
+\input{virtio-rpmb.tex}
 
 \chapter{Reserved Feature Bits}\label{sec:Reserved Feature Bits}
 
diff --git a/virtio-rpmb.tex b/virtio-rpmb.tex
new file mode 100644
index 0000000..b0b9ae1
--- /dev/null
+++ b/virtio-rpmb.tex
@@ -0,0 +1,88 @@
+\section{RPMB Device}\label{sec:Device Types / RPMB Device}
+
+virtio-rpmb is a virtio based RPMB (Replay Protected Memory Block)
+device. It is used as a tamper-resistant and anti-replay storage.
+It supports four command requests including read, write, get write
+counter and program key. They are placed in the queue.
+
+\subsection{Device ID}\label{sec:Device Types / RPMB Device / Device ID}
+
+28
+
+\subsection{Virtqueues}\label{sec:Device Types / RPMB Device / Virtqueues}
+
+\begin{description}
+\item[0] requestq
+\end{description}
+
+\subsection{Feature bits}\label{sec:Device Types / RPMB Device / Feature bits}
+
+None.
+
+\subsection{Device configuration layout}\label{sec:Device Types / RPMB Device / Device configuration layout}
+
+None.
+
+\subsection{Device Initialization}\label{sec:Device Types / RPMB Device / Device Initialization}
+
+\begin{enumerate}
+\item The virtqueue is initialized.
+\item The authentication key of device SHOULD NOT be programmed at the first initialization.
+\item The device size SHOULD be initialized to a multiple of 128 Kbytes and up to 16Mbytes.
+\end{enumerate}
+
+\subsection{Device Operation}\label{sec:Device Types / RPMB Device / Device Operation}
+
+The operation of a virtio RPMB device is driven by the requests placed on the virtqueue.
+  The type of the request can be program key (VIRTIO_RPMB_REQ_PROGRAM_KEY),
+  get write counter (VIRTIO_RPMB_REQ_GET_WRITE_COUNTER),
+  write (VIRTIO_RPMB_REQ_DATA_WRITE), and read (VIRTIO_RPMB_REQ_DATA_READ).
+  A program key or write request can also combine with a
+  result read (VIRTIO_RPMB_REQ_RESULT_READ) for a returned result.
+
+\begin{lstlisting}
+#define VIRTIO_RPMB_REQ_PROGRAM_KEY        0x0001
+#define VIRTIO_RPMB_REQ_GET_WRITE_COUNTER  0x0002
+#define VIRTIO_RPMB_REQ_DATA_WRITE         0x0003
+#define VIRTIO_RPMB_REQ_DATA_READ          0x0004
+#define VIRTIO_RPMB_REQ_RESULT_READ        0x0005
+\end{lstlisting}
+
+\drivernormative{\subsubsection}{Device Operation}{Device Types / RPMB Device / Device Operation}
+
+The driver MUST configure and initialize all virtqueues for the requests received.
+
+\devicenormative{\subsubsection}{Device Operation}{Device Types / RPMB Device / Device Operation}
+
+The device provides a simulated RPMB backed by ordinary file or
+  other medium in host. It SHOULD keep consistent behaviors with
+  hardware, including but not limited to:
+\begin{enumerate}
+\item The device maintains a monotonic write counter and an
+   authentication key. Once the first successful key programming
+   is performed, the authentication key MUST be kept unchanged
+   during device lifecycle. The monotonic write counter MUST be
+   added by one automatically after each successful write operation.
+\item The RPMB device cannot be accessed until RPMB authentication
+   key is programmed. For any operation (read, write, program key,
+   get write counter) done to virtio RPMB device after authentication
+   key is programmed successfully, the device responds with a MAC
+   calculated by authentication key with HMAC-SHA to driver.
+\item The device MUST authenticate write operation by MAC calculated
+   by authentication key and monotonic write counter .
+\end{enumerate}
+
+One of the below error codes MUST be returned to the driver
+  based on the operation result.
+
+\begin{lstlisting}
+#define VIRTIO_RPMB_RES_OK                     0x0000
+#define VIRTIO_RPMB_RES_GENERAL_FAILURE        0x0001
+#define VIRTIO_RPMB_RES_AUTH_FAILURE           0x0002
+#define VIRTIO_RPMB_RES_COUNT_FAILURE          0x0003
+#define VIRTIO_RPMB_RES_ADDR_FAILURE           0x0004
+#define VIRTIO_RPMB_RES_WRITE_FAILURE          0x0005
+#define VIRTIO_RPMB_RES_READ_FAILURE           0x0006
+#define VIRTIO_RPMB_RES_NO_AUTH_KEY            0x0007
+#define VIRTIO_RPMB_RES_WRITE_COUNTER_EXPIRED  0x0080
+\end{lstlisting}
-- 
2.7.4


This publicly archived list offers a means to provide input to the
OASIS Virtual I/O Device (VIRTIO) TC.

In order to verify user consent to the Feedback License terms and
to minimize spam in the list archive, subscription is required
before posting.

Subscribe: virtio-comment-subscribe@lists.oasis-open.org
Unsubscribe: virtio-comment-unsubscribe@lists.oasis-open.org
List help: virtio-comment-help@lists.oasis-open.org
List archive: https://lists.oasis-open.org/archives/virtio-comment/
Feedback License: https://www.oasis-open.org/who/ipr/feedback_license.pdf
List Guidelines: https://www.oasis-open.org/policies-guidelines/mailing-lists
Committee: https://www.oasis-open.org/committees/virtio/
Join OASIS: https://www.oasis-open.org/join/

[virtio-comment] Re: [PATCH] Add virtio rpmb device specification

[Michael S. Tsirkin]

On Mon, Jul 29, 2019 at 03:48:14PM +0800, Huang Yang wrote:
> It is a virtio based RPMB (Replay Protected Memory Block) device.
> 
> Signed-off-by: Yang Huang <yang.huang@intel.com>
> Reviewed-by: Bing Zhu <bing.zhu@intel.com>
> Reviewed-by: Tomas Winkler <tomas.winkler@intel.com> 
> 
> ---
>  conformance.tex | 18 +++++++++++-
>  content.tex     |  3 ++
>  virtio-rpmb.tex | 88 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>  3 files changed, 108 insertions(+), 1 deletion(-)
>  create mode 100644 virtio-rpmb.tex
> 
> diff --git a/conformance.tex b/conformance.tex
> index 0ac58aa..07166ba 100644
> --- a/conformance.tex
> +++ b/conformance.tex
> @@ -22,7 +22,7 @@ \section{Conformance Targets}\label{sec:Conformance / Conformance Targets}
>    \begin{itemize}
>      \item Clause \ref{sec:Conformance / Device Conformance}.
>      \item One of clauses \ref{sec:Conformance / Device Conformance / PCI Device Conformance}, \ref{sec:Conformance / Device Conformance / MMIO Device Conformance} or \ref{sec:Conformance / Device Conformance / Channel I/O Device Conformance}.
> -    \item One of clauses \ref{sec:Conformance / Device Conformance / Network Device Conformance}, \ref{sec:Conformance / Device Conformance / Block Device Conformance}, \ref{sec:Conformance / Device Conformance / Console Device Conformance}, \ref{sec:Conformance / Device Conformance / Entropy Device Conformance}, \ref{sec:Conformance / Device Conformance / Traditional Memory Balloon Device Conformance}, \ref{sec:Conformance / Device Conformance / SCSI Host Device Conformance}, \ref{sec:Conformance / Device Conformance / Input Device Conformance}, \ref{sec:Conformance / Device Conformance / Crypto Device Conformance} or \ref{sec:Conformance / Device Conformance / Socket Device Conformance}.
> +    \item One of clauses \ref{sec:Conformance / Device Conformance / Network Device Conformance}, \ref{sec:Conformance / Device Conformance / Block Device Conformance}, \ref{sec:Conformance / Device Conformance / Console Device Conformance}, \ref{sec:Conformance / Device Conformance / Entropy Device Conformance}, \ref{sec:Conformance / Device Conformance / Traditional Memory Balloon Device Conformance}, \ref{sec:Conformance / Device Conformance / SCSI Host Device Conformance}, \ref{sec:Conformance / Device Conformance / Input Device Conformance}, \ref{sec:Conformance / Device Conformance / Crypto Device Conformance}, \ref{sec:Conformance / Device Conformance / Socket Device Conformance} or \ref{sec:Conformance / Device Conformance / RPMB Device Conformance}.
>      \item Clause \ref{sec:Conformance / Legacy Interface: Transitional Device and Transitional Driver Conformance}.
>    \end{itemize}
>  \end{description}
> @@ -183,6 +183,14 @@ \section{Conformance Targets}\label{sec:Conformance / Conformance Targets}
>  \item \ref{drivernormative:Device Types / Socket Device / Device Operation / Device Events}
>  \end{itemize}
>  
> +\conformance{\subsection}{RPMB Driver Conformance}\label{sec:Conformance / Driver Conformance / RPMB Driver Conformance}
> +
> +A RPMB driver MUST conform to the following normative statements:
> +
> +\begin{itemize}
> +\item \ref{drivernormative:Device Types / RPMB Device / Device Operation}
> +\end{itemize}
> +
>  \conformance{\section}{Device Conformance}\label{sec:Conformance / Device Conformance}
>  
>  A device MUST conform to the following normative statements:
> @@ -338,6 +346,14 @@ \section{Conformance Targets}\label{sec:Conformance / Conformance Targets}
>  \item \ref{devicenormative:Device Types / Socket Device / Device Operation / Receive and Transmit}
>  \end{itemize}
>  
> +\conformance{\subsection}{RPMB Device Conformance}\label{sec:Conformance / Device Conformance / RPMB Device Conformance}
> +
> +An RPMB device MUST conform to the following normative statements:
> +
> +\begin{itemize}
> +\item \ref{devicenormative:Device Types / RPMB Device / Device Operation}
> +\end{itemize}
> +

Sorry this is not how we do it. Device and driver conformance are
separate sections, labeled appropriately. Device Operation should
include general prose that explains how they fit together.

>  \conformance{\section}{Legacy Interface: Transitional Device and Transitional Driver Conformance}\label{sec:Conformance / Legacy Interface: Transitional Device and Transitional Driver Conformance}
>  A conformant implementation MUST be either transitional or
>  non-transitional, see \ref{intro:Legacy
> diff --git a/content.tex b/content.tex
> index ee0d7c9..7f54f94 100644
> --- a/content.tex
> +++ b/content.tex
> @@ -2717,6 +2717,8 @@ \chapter{Device Types}\label{sec:Device Types}
>  \hline
>  27         &   PMEM device \\
>  \hline
> +28         &   RPMB device \\
> +\hline
>  \end{tabular}
>  
>  Some of the devices above are unspecified by this document,
> @@ -5677,6 +5679,7 @@ \subsubsection{Legacy Interface: Framing Requirements}\label{sec:Device
>  \input{virtio-input.tex}
>  \input{virtio-crypto.tex}
>  \input{virtio-vsock.tex}
> +\input{virtio-rpmb.tex}
>  
>  \chapter{Reserved Feature Bits}\label{sec:Reserved Feature Bits}
>  
> diff --git a/virtio-rpmb.tex b/virtio-rpmb.tex
> new file mode 100644
> index 0000000..b0b9ae1
> --- /dev/null
> +++ b/virtio-rpmb.tex
> @@ -0,0 +1,88 @@
> +\section{RPMB Device}\label{sec:Device Types / RPMB Device}
> +
> +virtio-rpmb is a virtio based RPMB (Replay Protected Memory Block)
> +device. It is used as a tamper-resistant and anti-replay storage.
> +It supports four command requests including read, write, get write
> +counter and program key. They are placed in the queue.
> +
> +\subsection{Device ID}\label{sec:Device Types / RPMB Device / Device ID}
> +
> +28
> +
> +\subsection{Virtqueues}\label{sec:Device Types / RPMB Device / Virtqueues}
> +
> +\begin{description}
> +\item[0] requestq
> +\end{description}
> +
> +\subsection{Feature bits}\label{sec:Device Types / RPMB Device / Feature bits}
> +
> +None.
> +
> +\subsection{Device configuration layout}\label{sec:Device Types / RPMB Device / Device configuration layout}
> +
> +None.
> +
> +\subsection{Device Initialization}\label{sec:Device Types / RPMB Device / Device Initialization}

Below and everywhere, each conformance statement belongs to either
device or driver, listing either device or driver and
moved to the appropriate conformance section.

> +
> +\begin{enumerate}
> +\item The virtqueue is initialized.
> +\item The authentication key of device SHOULD NOT be programmed at the first initialization.

what does this imply exactly? what is "first initialization"? first
after which event? device reset?

> +\item The device size SHOULD be initialized to a multiple of 128 Kbytes and up to 16Mbytes.

what is device size and how does it affect operation?

> +\end{enumerate}
> +
> +\subsection{Device Operation}\label{sec:Device Types / RPMB Device / Device Operation}
> +
> +The operation of a virtio RPMB device is driven by the requests placed on the virtqueue.
> +  The type of the request can be program key (VIRTIO_RPMB_REQ_PROGRAM_KEY),
> +  get write counter (VIRTIO_RPMB_REQ_GET_WRITE_COUNTER),
> +  write (VIRTIO_RPMB_REQ_DATA_WRITE), and read (VIRTIO_RPMB_REQ_DATA_READ).
> +  A program key or write request can also combine with a
> +  result read (VIRTIO_RPMB_REQ_RESULT_READ) for a returned result.
> +
> +\begin{lstlisting}
> +#define VIRTIO_RPMB_REQ_PROGRAM_KEY        0x0001
> +#define VIRTIO_RPMB_REQ_GET_WRITE_COUNTER  0x0002
> +#define VIRTIO_RPMB_REQ_DATA_WRITE         0x0003
> +#define VIRTIO_RPMB_REQ_DATA_READ          0x0004
> +#define VIRTIO_RPMB_REQ_RESULT_READ        0x0005
> +\end{lstlisting}

OK but what are these numbers in aid of? Does driver pass
these values to the device somehow?

> +
> +\drivernormative{\subsubsection}{Device Operation}{Device Types / RPMB Device / Device Operation}
> +
> +The driver MUST configure and initialize all virtqueues for the requests received.
> +
> +\devicenormative{\subsubsection}{Device Operation}{Device Types / RPMB Device / Device Operation}
> +
> +The device provides a simulated RPMB backed by ordinary file or
> +  other medium in host. It SHOULD keep consistent behaviors with
> +  hardware, including but not limited to:
> +\begin{enumerate}
> +\item The device maintains a monotonic write counter and an
> +   authentication key. Once the first successful key programming
> +   is performed, the authentication key MUST be kept unchanged
> +   during device lifecycle. The monotonic write counter MUST be
> +   added by one automatically after each successful write operation.
> +\item The RPMB device cannot be accessed until RPMB authentication

until after?

> +   key is programmed. 

and until device reset?

>For any operation (read, write, program key,
> +   get write counter) done to virtio RPMB device after authentication
> +   key is programmed successfully, the device responds with a MAC
> +   calculated by authentication key with HMAC-SHA to driver.

responds how?

> +\item The device MUST authenticate write operation by MAC calculated
> +   by authentication key and monotonic write counter .

authenticate how?

> +\end{enumerate}
> +
> +One of the below error codes MUST be returned to the driver
> +  based on the operation result.

how are they returned to driver?

> +
> +\begin{lstlisting}
> +#define VIRTIO_RPMB_RES_OK                     0x0000
> +#define VIRTIO_RPMB_RES_GENERAL_FAILURE        0x0001
> +#define VIRTIO_RPMB_RES_AUTH_FAILURE           0x0002
> +#define VIRTIO_RPMB_RES_COUNT_FAILURE          0x0003
> +#define VIRTIO_RPMB_RES_ADDR_FAILURE           0x0004
> +#define VIRTIO_RPMB_RES_WRITE_FAILURE          0x0005
> +#define VIRTIO_RPMB_RES_READ_FAILURE           0x0006
> +#define VIRTIO_RPMB_RES_NO_AUTH_KEY            0x0007
> +#define VIRTIO_RPMB_RES_WRITE_COUNTER_EXPIRED  0x0080
> +\end{lstlisting}
> -- 
> 2.7.4

This publicly archived list offers a means to provide input to the
OASIS Virtual I/O Device (VIRTIO) TC.

In order to verify user consent to the Feedback License terms and
to minimize spam in the list archive, subscription is required
before posting.

Subscribe: virtio-comment-subscribe@lists.oasis-open.org
Unsubscribe: virtio-comment-unsubscribe@lists.oasis-open.org
List help: virtio-comment-help@lists.oasis-open.org
List archive: https://lists.oasis-open.org/archives/virtio-comment/
Feedback License: https://www.oasis-open.org/who/ipr/feedback_license.pdf
List Guidelines: https://www.oasis-open.org/policies-guidelines/mailing-lists
Committee: https://www.oasis-open.org/committees/virtio/
Join OASIS: https://www.oasis-open.org/join/

RE: [virtio-comment] Re: [PATCH] Add virtio rpmb device specification

[Huang, Yang]

Let me give a simple introduction on RPMB operation.

This is the RPMB frame for request and response:
Stuff       | Key/MAC |   Data  |  Nonce | Write Counter | Address | Block Count | Result | Req/Resp
196B               32B          256B        16B                4B                    2B                  2B                 2B            2B
[511:316][315:284]   [283:28]  [27:12]          [11:8]              [7:6]              [5:4]              [3:2]       [1:0]

Guest will fill this RPMB frame per request and send it to driver. Driver then format it to vqueue and send to device.
After device receive it, it will parse the frame, do authentication and fill a new frame with the result, data, MAC, Resp etc.
The new frame will be responded to driver for guest.


> > @@ -183,6 +183,14 @@ \section{Conformance
> > Targets}\label{sec:Conformance / Conformance Targets}  \item
> > \ref{drivernormative:Device Types / Socket Device / Device Operation /
> > Device Events}  \end{itemize}
> >
> > +\conformance{\subsection}{RPMB Driver
> > +Conformance}\label{sec:Conformance / Driver Conformance / RPMB Driver
> > +Conformance}
> > +
> > +A RPMB driver MUST conform to the following normative statements:
> > +
> > +\begin{itemize}
> > +\item \ref{drivernormative:Device Types / RPMB Device / Device
> > +Operation} \end{itemize}
> > +
> >  \conformance{\section}{Device Conformance}\label{sec:Conformance /
> > Device Conformance}
> >
> >  A device MUST conform to the following normative statements:
> > @@ -338,6 +346,14 @@ \section{Conformance
> > Targets}\label{sec:Conformance / Conformance Targets}  \item
> > \ref{devicenormative:Device Types / Socket Device / Device Operation /
> > Receive and Transmit}  \end{itemize}
> >
> > +\conformance{\subsection}{RPMB Device
> > +Conformance}\label{sec:Conformance / Device Conformance / RPMB Device
> > +Conformance}
> > +
> > +An RPMB device MUST conform to the following normative statements:
> > +
> > +\begin{itemize}
> > +\item \ref{devicenormative:Device Types / RPMB Device / Device
> > +Operation} \end{itemize}
> > +
> 
> Sorry this is not how we do it. Device and driver conformance are separate
> sections, labeled appropriately. Device Operation should include general prose
> that explains how they fit together.
>
> >  \conformance{\section}{Legacy Interface: Transitional Device and
> > Transitional Driver Conformance}\label{sec:Conformance / Legacy
> > Interface: Transitional Device and Transitional Driver Conformance}  A
> > conformant implementation MUST be either transitional or
> > non-transitional, see \ref{intro:Legacy diff --git a/content.tex
> > b/content.tex index ee0d7c9..7f54f94 100644
> > --- a/content.tex
> > +++ b/content.tex
> > @@ -2717,6 +2717,8 @@ \chapter{Device Types}\label{sec:Device Types}
> > \hline
> >  27         &   PMEM device \\
> >  \hline
> > +28         &   RPMB device \\
> > +\hline
> >  \end{tabular}
> >
> >  Some of the devices above are unspecified by this document, @@
> > -5677,6 +5679,7 @@ \subsubsection{Legacy Interface: Framing
> > Requirements}\label{sec:Device  \input{virtio-input.tex}
> > \input{virtio-crypto.tex}  \input{virtio-vsock.tex}
> > +\input{virtio-rpmb.tex}
> >
> >  \chapter{Reserved Feature Bits}\label{sec:Reserved Feature Bits}
> >
> > diff --git a/virtio-rpmb.tex b/virtio-rpmb.tex new file mode 100644
> > index 0000000..b0b9ae1
> > --- /dev/null
> > +++ b/virtio-rpmb.tex
> > @@ -0,0 +1,88 @@
> > +\section{RPMB Device}\label{sec:Device Types / RPMB Device}
> > +
> > +virtio-rpmb is a virtio based RPMB (Replay Protected Memory Block)
> > +device. It is used as a tamper-resistant and anti-replay storage.
> > +It supports four command requests including read, write, get write
> > +counter and program key. They are placed in the queue.
> > +
> > +\subsection{Device ID}\label{sec:Device Types / RPMB Device / Device
> > +ID}
> > +
> > +28
> > +
> > +\subsection{Virtqueues}\label{sec:Device Types / RPMB Device /
> > +Virtqueues}
> > +
> > +\begin{description}
> > +\item[0] requestq
> > +\end{description}
> > +
> > +\subsection{Feature bits}\label{sec:Device Types / RPMB Device /
> > +Feature bits}
> > +
> > +None.
> > +
> > +\subsection{Device configuration layout}\label{sec:Device Types /
> > +RPMB Device / Device configuration layout}
> > +
> > +None.
> > +
> > +\subsection{Device Initialization}\label{sec:Device Types / RPMB
> > +Device / Device Initialization}
> 
> Below and everywhere, each conformance statement belongs to either device
> or driver, listing either device or driver and moved to the appropriate
> conformance section.

OK. Thanks.

> > +
> > +\begin{enumerate}
> > +\item The virtqueue is initialized.
> > +\item The authentication key of device SHOULD NOT be programmed at the
> first initialization.
> 
> what does this imply exactly? what is "first initialization"? first after which event?
> device reset?
> 
> > +\item The device size SHOULD be initialized to a multiple of 128 Kbytes and up
> to 16Mbytes.
> 
> what is device size and how does it affect operation?

It refers to the capacity of RPMB. I will change the wording.
It is the rule in Spec. So keep consistent with hardware.
For RPMB, the block size is 256B, and the address is UINT16.
So the max capacity is 256B * 2^16 = 16MB.
Invalid address access will be returned with a VIRTIO_RPMB_RES_AUTH_FAILURE defined below.

> > +\end{enumerate}
> > +
> > +\subsection{Device Operation}\label{sec:Device Types / RPMB Device /
> > +Device Operation}
> > +
> > +The operation of a virtio RPMB device is driven by the requests placed on the
> virtqueue.
> > +  The type of the request can be program key
> > +(VIRTIO_RPMB_REQ_PROGRAM_KEY),
> > +  get write counter (VIRTIO_RPMB_REQ_GET_WRITE_COUNTER),
> > +  write (VIRTIO_RPMB_REQ_DATA_WRITE), and read
> (VIRTIO_RPMB_REQ_DATA_READ).
> > +  A program key or write request can also combine with a
> > +  result read (VIRTIO_RPMB_REQ_RESULT_READ) for a returned result.
> > +
> > +\begin{lstlisting}
> > +#define VIRTIO_RPMB_REQ_PROGRAM_KEY        0x0001
> > +#define VIRTIO_RPMB_REQ_GET_WRITE_COUNTER  0x0002
> > +#define VIRTIO_RPMB_REQ_DATA_WRITE         0x0003
> > +#define VIRTIO_RPMB_REQ_DATA_READ          0x0004
> > +#define VIRTIO_RPMB_REQ_RESULT_READ        0x0005
> > +\end{lstlisting}
> 
> OK but what are these numbers in aid of? Does driver pass these values to the
> device somehow?

The numbers are used as request type (Req/Resp) in RPMB frame to specify a operation on RPMB like read/write/get writer counter/program key.
Driver will pass the whole data frame to device.

> > +
> > +\drivernormative{\subsubsection}{Device Operation}{Device Types /
> > +RPMB Device / Device Operation}
> > +
> > +The driver MUST configure and initialize all virtqueues for the requests
> received.
> > +
> > +\devicenormative{\subsubsection}{Device Operation}{Device Types /
> > +RPMB Device / Device Operation}
> > +
> > +The device provides a simulated RPMB backed by ordinary file or
> > +  other medium in host. It SHOULD keep consistent behaviors with
> > +  hardware, including but not limited to:
> > +\begin{enumerate}
> > +\item The device maintains a monotonic write counter and an
> > +   authentication key. Once the first successful key programming
> > +   is performed, the authentication key MUST be kept unchanged
> > +   during device lifecycle. The monotonic write counter MUST be
> > +   added by one automatically after each successful write operation.
> > +\item The RPMB device cannot be accessed until RPMB authentication
> 
> until after?

Yes. After.

> > +   key is programmed.
> 
> and until device reset?

After RPMB authentication key is successful programmed, it will be saved by device and kept unchanged regardless of device reset or reboot.

> >For any operation (read, write, program key,
> > +   get write counter) done to virtio RPMB device after authentication
> > +   key is programmed successfully, the device responds with a MAC
> > +   calculated by authentication key with HMAC-SHA to driver.
> 
> responds how?

it is filled to the MAC of RPMB frame. And the frame is responded to driver.

> > +\item The device MUST authenticate write operation by MAC calculated
> > +   by authentication key and monotonic write counter .
> 
> authenticate how?

1. compare the monotonic write counter in RPMB frame with the one recorded in device. Make sure the two values are equal. This counter protects from replay attack.
2. calculate the MAC by RPMB key(recorded by device at the first program key request from guest) and the RPMB frame received from driver. Compare this MAC with the MAC in RPMB frame. Make sure the two MACs are same. It protects data from tampering by the attacks who doesn't have RPMB key.
After 1&2 are authenticated, a write operation will be performed.

Should include these details into spec?

> > +\end{enumerate}
> > +
> > +One of the below error codes MUST be returned to the driver
> > +  based on the operation result.
> 
> how are they returned to driver?

Device puts the error code to the Result of RPMB frame and pass the data frame to driver.

> > +
> > +\begin{lstlisting}
> > +#define VIRTIO_RPMB_RES_OK                     0x0000
> > +#define VIRTIO_RPMB_RES_GENERAL_FAILURE        0x0001
> > +#define VIRTIO_RPMB_RES_AUTH_FAILURE           0x0002
> > +#define VIRTIO_RPMB_RES_COUNT_FAILURE          0x0003
> > +#define VIRTIO_RPMB_RES_ADDR_FAILURE           0x0004
> > +#define VIRTIO_RPMB_RES_WRITE_FAILURE          0x0005
> > +#define VIRTIO_RPMB_RES_READ_FAILURE           0x0006
> > +#define VIRTIO_RPMB_RES_NO_AUTH_KEY            0x0007
> > +#define VIRTIO_RPMB_RES_WRITE_COUNTER_EXPIRED  0x0080
> > +\end{lstlisting}



This publicly archived list offers a means to provide input to the
OASIS Virtual I/O Device (VIRTIO) TC.

In order to verify user consent to the Feedback License terms and
to minimize spam in the list archive, subscription is required
before posting.

Subscribe: virtio-comment-subscribe@lists.oasis-open.org
Unsubscribe: virtio-comment-unsubscribe@lists.oasis-open.org
List help: virtio-comment-help@lists.oasis-open.org
List archive: https://lists.oasis-open.org/archives/virtio-comment/
Feedback License: https://www.oasis-open.org/who/ipr/feedback_license.pdf
List Guidelines: https://www.oasis-open.org/policies-guidelines/mailing-lists
Committee: https://www.oasis-open.org/committees/virtio/
Join OASIS: https://www.oasis-open.org/join/

Re: [virtio-comment] Re: [PATCH] Add virtio rpmb device specification

[Michael S. Tsirkin]

On Tue, Jul 30, 2019 at 05:51:24AM +0000, Huang, Yang wrote:
> > > +\item The device MUST authenticate write operation by MAC calculated
> > > +   by authentication key and monotonic write counter .
> > 
> > authenticate how?
> 
> 1. compare the monotonic write counter in RPMB frame with the one recorded in device. Make sure the two values are equal. This counter protects from replay attack.
> 2. calculate the MAC by RPMB key(recorded by device at the first program key request from guest) and the RPMB frame received from driver. Compare this MAC with the MAC in RPMB frame. Make sure the two MACs are same. It protects data from tampering by the attacks who doesn't have RPMB key.
> After 1&2 are authenticated, a write operation will be performed.
> 
> Should include these details into spec?

Looks more like validation.

So if you add a conformance statement you need
to explain what is the device supposed to do.

E.g if you talk about write counter define what it is previously.



-- 
MST

This publicly archived list offers a means to provide input to the
OASIS Virtual I/O Device (VIRTIO) TC.

In order to verify user consent to the Feedback License terms and
to minimize spam in the list archive, subscription is required
before posting.

Subscribe: virtio-comment-subscribe@lists.oasis-open.org
Unsubscribe: virtio-comment-unsubscribe@lists.oasis-open.org
List help: virtio-comment-help@lists.oasis-open.org
List archive: https://lists.oasis-open.org/archives/virtio-comment/
Feedback License: https://www.oasis-open.org/who/ipr/feedback_license.pdf
List Guidelines: https://www.oasis-open.org/policies-guidelines/mailing-lists
Committee: https://www.oasis-open.org/committees/virtio/
Join OASIS: https://www.oasis-open.org/join/

Re: [virtio-comment] [PATCH] Add virtio rpmb device specification

[Paolo Bonzini]

On 29/07/19 09:48, Huang Yang wrote:
>  
> But virtualization software like Qemu doesn't provide eMMC/UFS/NVMe
> RPMB emulation. It blocks the OS like Trusty or OP-TEE running in a
> virtualization environment. For instance, Google right now uses another
> way to work around RPMB emulation issue when running Trusty in ARM Qemu:
> https://android.googlesource.com/trusty/external/trusty/+/refs/heads/master/test-runner/
> 
> Virtio RPMB standardization will definitely benefit OP-TEE,
> Google Trusty TEE, Qemu, OVMF or other modules to develop the RPMB
> based secure storage in virtualization.
>  

Is there any reason to use a new virtio-blk device, and not add this
functionality to virtio-blk?

Paolo

This publicly archived list offers a means to provide input to the
OASIS Virtual I/O Device (VIRTIO) TC.

In order to verify user consent to the Feedback License terms and
to minimize spam in the list archive, subscription is required
before posting.

Subscribe: virtio-comment-subscribe@lists.oasis-open.org
Unsubscribe: virtio-comment-unsubscribe@lists.oasis-open.org
List help: virtio-comment-help@lists.oasis-open.org
List archive: https://lists.oasis-open.org/archives/virtio-comment/
Feedback License: https://www.oasis-open.org/who/ipr/feedback_license.pdf
List Guidelines: https://www.oasis-open.org/policies-guidelines/mailing-lists
Committee: https://www.oasis-open.org/committees/virtio/
Join OASIS: https://www.oasis-open.org/join/

RE: [virtio-comment] [PATCH] Add virtio rpmb device specification

[Huang, Yang]

> -----Original Message-----
> From: virtio-comment@lists.oasis-open.org [mailto:virtio-comment@lists.oasis-
> open.org] On Behalf Of Paolo Bonzini
> Sent: Monday, July 29, 2019 17:19
> To: Huang, Yang <yang.huang@intel.com>; virtio-dev@lists.oasis-open.org
> Cc: virtio-comment@lists.oasis-open.org; mst@redhat.com; Zhu, Bing
> <bing.zhu@intel.com>; Winkler, Tomas <tomas.winkler@intel.com>
> Subject: Re: [virtio-comment] [PATCH] Add virtio rpmb device specification
> 
> On 29/07/19 09:48, Huang Yang wrote:
> >
> > But virtualization software like Qemu doesn't provide eMMC/UFS/NVMe
> > RPMB emulation. It blocks the OS like Trusty or OP-TEE running in a
> > virtualization environment. For instance, Google right now uses
> > another way to work around RPMB emulation issue when running Trusty in
> ARM Qemu:
> > https://android.googlesource.com/trusty/external/trusty/+/refs/heads/m
> > aster/test-runner/
> >
> > Virtio RPMB standardization will definitely benefit OP-TEE, Google
> > Trusty TEE, Qemu, OVMF or other modules to develop the RPMB based
> > secure storage in virtualization.
> >
> 
> Is there any reason to use a new virtio-blk device, and not add this functionality
> to virtio-blk?
> 
> Paolo

RPMB does not behave as a blk device. It doesn't have block device APIs.
Current virtio blk features or definitions in spec are mostly useless or inapplicable to virtio rpmb.
It performs a different behaviors from the operations on a blk device. 
Key, writer counter or nonce are required to read/write on it.
If add it to blk device, it will not only cause to a higher complexity, but also cause to two different behaviors on a same device.

Re: [virtio-comment] [PATCH] Add virtio rpmb device specification

[Michael S. Tsirkin]

On Tue, Jul 30, 2019 at 12:33:17AM +0000, Huang, Yang wrote:
> 
> 
> > -----Original Message-----
> > From: virtio-comment@lists.oasis-open.org [mailto:virtio-comment@lists.oasis-
> > open.org] On Behalf Of Paolo Bonzini
> > Sent: Monday, July 29, 2019 17:19
> > To: Huang, Yang <yang.huang@intel.com>; virtio-dev@lists.oasis-open.org
> > Cc: virtio-comment@lists.oasis-open.org; mst@redhat.com; Zhu, Bing
> > <bing.zhu@intel.com>; Winkler, Tomas <tomas.winkler@intel.com>
> > Subject: Re: [virtio-comment] [PATCH] Add virtio rpmb device specification
> > 
> > On 29/07/19 09:48, Huang Yang wrote:
> > >
> > > But virtualization software like Qemu doesn't provide eMMC/UFS/NVMe
> > > RPMB emulation. It blocks the OS like Trusty or OP-TEE running in a
> > > virtualization environment. For instance, Google right now uses
> > > another way to work around RPMB emulation issue when running Trusty in
> > ARM Qemu:
> > > https://android.googlesource.com/trusty/external/trusty/+/refs/heads/m
> > > aster/test-runner/
> > >
> > > Virtio RPMB standardization will definitely benefit OP-TEE, Google
> > > Trusty TEE, Qemu, OVMF or other modules to develop the RPMB based
> > > secure storage in virtualization.
> > >
> > 
> > Is there any reason to use a new virtio-blk device, and not add this functionality
> > to virtio-blk?
> > 
> > Paolo
> 
> RPMB does not behave as a blk device. It doesn't have block device APIs.
> Current virtio blk features or definitions in spec are mostly useless or inapplicable to virtio rpmb.
> It performs a different behaviors from the operations on a blk device. 
> Key, writer counter or nonce are required to read/write on it.
> If add it to blk device, it will not only cause to a higher complexity, but also cause to two different behaviors on a same device.
> 


Well it seems that current RPMB implementations are all tied to
a storage device, like MMC or NVMe. Why is that and why doesn't
the same logic apply here?

-- 
MST

This publicly archived list offers a means to provide input to the
OASIS Virtual I/O Device (VIRTIO) TC.

In order to verify user consent to the Feedback License terms and
to minimize spam in the list archive, subscription is required
before posting.

Subscribe: virtio-comment-subscribe@lists.oasis-open.org
Unsubscribe: virtio-comment-unsubscribe@lists.oasis-open.org
List help: virtio-comment-help@lists.oasis-open.org
List archive: https://lists.oasis-open.org/archives/virtio-comment/
Feedback License: https://www.oasis-open.org/who/ipr/feedback_license.pdf
List Guidelines: https://www.oasis-open.org/policies-guidelines/mailing-lists
Committee: https://www.oasis-open.org/committees/virtio/
Join OASIS: https://www.oasis-open.org/join/

[virtio-comment] RE: [virtio-dev] Re: [virtio-comment] [PATCH] Add virtio rpmb device specification

[Huang, Yang]

> -----Original Message-----
> From: virtio-dev@lists.oasis-open.org [mailto:virtio-dev@lists.oasis-open.org]
> On Behalf Of Michael S. Tsirkin
> Sent: Sunday, August 4, 2019 5:00
> To: Huang, Yang <yang.huang@intel.com>
> Cc: Paolo Bonzini <pbonzini@redhat.com>; virtio-dev@lists.oasis-open.org;
> virtio-comment@lists.oasis-open.org; Zhu, Bing <bing.zhu@intel.com>; Winkler,
> Tomas <tomas.winkler@intel.com>
> Subject: [virtio-dev] Re: [virtio-comment] [PATCH] Add virtio rpmb device
> specification
> 
> On Tue, Jul 30, 2019 at 12:33:17AM +0000, Huang, Yang wrote:
> >
> >
> > > -----Original Message-----
> > > From: virtio-comment@lists.oasis-open.org
> > > [mailto:virtio-comment@lists.oasis-
> > > open.org] On Behalf Of Paolo Bonzini
> > > Sent: Monday, July 29, 2019 17:19
> > > To: Huang, Yang <yang.huang@intel.com>;
> > > virtio-dev@lists.oasis-open.org
> > > Cc: virtio-comment@lists.oasis-open.org; mst@redhat.com; Zhu, Bing
> > > <bing.zhu@intel.com>; Winkler, Tomas <tomas.winkler@intel.com>
> > > Subject: Re: [virtio-comment] [PATCH] Add virtio rpmb device
> > > specification
> > >
> > > On 29/07/19 09:48, Huang Yang wrote:
> > > >
> > > > But virtualization software like Qemu doesn't provide
> > > > eMMC/UFS/NVMe RPMB emulation. It blocks the OS like Trusty or
> > > > OP-TEE running in a virtualization environment. For instance,
> > > > Google right now uses another way to work around RPMB emulation
> > > > issue when running Trusty in
> > > ARM Qemu:
> > > > https://android.googlesource.com/trusty/external/trusty/+/refs/hea
> > > > ds/m
> > > > aster/test-runner/
> > > >
> > > > Virtio RPMB standardization will definitely benefit OP-TEE, Google
> > > > Trusty TEE, Qemu, OVMF or other modules to develop the RPMB based
> > > > secure storage in virtualization.
> > > >
> > >
> > > Is there any reason to use a new virtio-blk device, and not add this
> > > functionality to virtio-blk?
> > >
> > > Paolo
> >
> > RPMB does not behave as a blk device. It doesn't have block device APIs.
> > Current virtio blk features or definitions in spec are mostly useless or
> inapplicable to virtio rpmb.
> > It performs a different behaviors from the operations on a blk device.
> > Key, writer counter or nonce are required to read/write on it.
> > If add it to blk device, it will not only cause to a higher complexity, but also
> cause to two different behaviors on a same device.
> >
> 
> 
> Well it seems that current RPMB implementations are all tied to a storage device,
> like MMC or NVMe. Why is that and why doesn't the same logic apply here?
> 
> --
> MST
> 

RPMB is a mandatory hardware partition of eMMC, UFS and optional for NVMe.
It is standardized by JEDEC and NVMe. 
This partition is different from the user data partition that blk device emulates.
It provides a signed access in an authenticated and replay protected manner that
blk device does not perform. Only RPMB key owner can write to it while anybody
can access to a user data partition.


This publicly archived list offers a means to provide input to the
OASIS Virtual I/O Device (VIRTIO) TC.

In order to verify user consent to the Feedback License terms and
to minimize spam in the list archive, subscription is required
before posting.

Subscribe: virtio-comment-subscribe@lists.oasis-open.org
Unsubscribe: virtio-comment-unsubscribe@lists.oasis-open.org
List help: virtio-comment-help@lists.oasis-open.org
List archive: https://lists.oasis-open.org/archives/virtio-comment/
Feedback License: https://www.oasis-open.org/who/ipr/feedback_license.pdf
List Guidelines: https://www.oasis-open.org/policies-guidelines/mailing-lists
Committee: https://www.oasis-open.org/committees/virtio/
Join OASIS: https://www.oasis-open.org/join/

Re: [virtio-comment] RE: [virtio-dev] Re: [virtio-comment] [PATCH] Add virtio rpmb device specification

[Michael S. Tsirkin]

On Sun, Aug 04, 2019 at 02:07:49AM +0000, Huang, Yang wrote:
> 
> 
> > -----Original Message-----
> > From: virtio-dev@lists.oasis-open.org [mailto:virtio-dev@lists.oasis-open.org]
> > On Behalf Of Michael S. Tsirkin
> > Sent: Sunday, August 4, 2019 5:00
> > To: Huang, Yang <yang.huang@intel.com>
> > Cc: Paolo Bonzini <pbonzini@redhat.com>; virtio-dev@lists.oasis-open.org;
> > virtio-comment@lists.oasis-open.org; Zhu, Bing <bing.zhu@intel.com>; Winkler,
> > Tomas <tomas.winkler@intel.com>
> > Subject: [virtio-dev] Re: [virtio-comment] [PATCH] Add virtio rpmb device
> > specification
> > 
> > On Tue, Jul 30, 2019 at 12:33:17AM +0000, Huang, Yang wrote:
> > >
> > >
> > > > -----Original Message-----
> > > > From: virtio-comment@lists.oasis-open.org
> > > > [mailto:virtio-comment@lists.oasis-
> > > > open.org] On Behalf Of Paolo Bonzini
> > > > Sent: Monday, July 29, 2019 17:19
> > > > To: Huang, Yang <yang.huang@intel.com>;
> > > > virtio-dev@lists.oasis-open.org
> > > > Cc: virtio-comment@lists.oasis-open.org; mst@redhat.com; Zhu, Bing
> > > > <bing.zhu@intel.com>; Winkler, Tomas <tomas.winkler@intel.com>
> > > > Subject: Re: [virtio-comment] [PATCH] Add virtio rpmb device
> > > > specification
> > > >
> > > > On 29/07/19 09:48, Huang Yang wrote:
> > > > >
> > > > > But virtualization software like Qemu doesn't provide
> > > > > eMMC/UFS/NVMe RPMB emulation. It blocks the OS like Trusty or
> > > > > OP-TEE running in a virtualization environment. For instance,
> > > > > Google right now uses another way to work around RPMB emulation
> > > > > issue when running Trusty in
> > > > ARM Qemu:
> > > > > https://android.googlesource.com/trusty/external/trusty/+/refs/hea
> > > > > ds/m
> > > > > aster/test-runner/
> > > > >
> > > > > Virtio RPMB standardization will definitely benefit OP-TEE, Google
> > > > > Trusty TEE, Qemu, OVMF or other modules to develop the RPMB based
> > > > > secure storage in virtualization.
> > > > >
> > > >
> > > > Is there any reason to use a new virtio-blk device, and not add this
> > > > functionality to virtio-blk?
> > > >
> > > > Paolo
> > >
> > > RPMB does not behave as a blk device. It doesn't have block device APIs.
> > > Current virtio blk features or definitions in spec are mostly useless or
> > inapplicable to virtio rpmb.
> > > It performs a different behaviors from the operations on a blk device.
> > > Key, writer counter or nonce are required to read/write on it.
> > > If add it to blk device, it will not only cause to a higher complexity, but also
> > cause to two different behaviors on a same device.
> > >
> > 
> > 
> > Well it seems that current RPMB implementations are all tied to a storage device,
> > like MMC or NVMe. Why is that and why doesn't the same logic apply here?
> > 
> > --
> > MST
> > 
> 
> RPMB is a mandatory hardware partition of eMMC, UFS and optional for NVMe.
> It is standardized by JEDEC and NVMe. 
> This partition is different from the user data partition that blk device emulates.
> It provides a signed access in an authenticated and replay protected manner that
> blk device does not perform. Only RPMB key owner can write to it while anybody
> can access to a user data partition.

Sorry if I'm being dense, so how is this different from e.g. NVMe?

-- 
MST

This publicly archived list offers a means to provide input to the
OASIS Virtual I/O Device (VIRTIO) TC.

In order to verify user consent to the Feedback License terms and
to minimize spam in the list archive, subscription is required
before posting.

Subscribe: virtio-comment-subscribe@lists.oasis-open.org
Unsubscribe: virtio-comment-unsubscribe@lists.oasis-open.org
List help: virtio-comment-help@lists.oasis-open.org
List archive: https://lists.oasis-open.org/archives/virtio-comment/
Feedback License: https://www.oasis-open.org/who/ipr/feedback_license.pdf
List Guidelines: https://www.oasis-open.org/policies-guidelines/mailing-lists
Committee: https://www.oasis-open.org/committees/virtio/
Join OASIS: https://www.oasis-open.org/join/

RE: [virtio-comment] RE: [virtio-dev] Re: [virtio-comment] [PATCH] Add virtio rpmb device specification

[Huang, Yang]

> -----Original Message-----
> From: Michael S. Tsirkin [mailto:mst@redhat.com]
> Sent: Sunday, August 4, 2019 15:49
> To: Huang, Yang <yang.huang@intel.com>
> Cc: Paolo Bonzini <pbonzini@redhat.com>; virtio-dev@lists.oasis-open.org;
> virtio-comment@lists.oasis-open.org; Zhu, Bing <bing.zhu@intel.com>; Winkler,
> Tomas <tomas.winkler@intel.com>
> Subject: Re: [virtio-comment] RE: [virtio-dev] Re: [virtio-comment] [PATCH] Add
> virtio rpmb device specification
> 
> On Sun, Aug 04, 2019 at 02:07:49AM +0000, Huang, Yang wrote:
> >
> >
> > > -----Original Message-----
> > > From: virtio-dev@lists.oasis-open.org
> > > [mailto:virtio-dev@lists.oasis-open.org]
> > > On Behalf Of Michael S. Tsirkin
> > > Sent: Sunday, August 4, 2019 5:00
> > > To: Huang, Yang <yang.huang@intel.com>
> > > Cc: Paolo Bonzini <pbonzini@redhat.com>;
> > > virtio-dev@lists.oasis-open.org;
> > > virtio-comment@lists.oasis-open.org; Zhu, Bing <bing.zhu@intel.com>;
> > > Winkler, Tomas <tomas.winkler@intel.com>
> > > Subject: [virtio-dev] Re: [virtio-comment] [PATCH] Add virtio rpmb
> > > device specification
> > >
> > > On Tue, Jul 30, 2019 at 12:33:17AM +0000, Huang, Yang wrote:
> > > >
> > > >
> > > > > -----Original Message-----
> > > > > From: virtio-comment@lists.oasis-open.org
> > > > > [mailto:virtio-comment@lists.oasis-
> > > > > open.org] On Behalf Of Paolo Bonzini
> > > > > Sent: Monday, July 29, 2019 17:19
> > > > > To: Huang, Yang <yang.huang@intel.com>;
> > > > > virtio-dev@lists.oasis-open.org
> > > > > Cc: virtio-comment@lists.oasis-open.org; mst@redhat.com; Zhu,
> > > > > Bing <bing.zhu@intel.com>; Winkler, Tomas
> > > > > <tomas.winkler@intel.com>
> > > > > Subject: Re: [virtio-comment] [PATCH] Add virtio rpmb device
> > > > > specification
> > > > >
> > > > > On 29/07/19 09:48, Huang Yang wrote:
> > > > > >
> > > > > > But virtualization software like Qemu doesn't provide
> > > > > > eMMC/UFS/NVMe RPMB emulation. It blocks the OS like Trusty or
> > > > > > OP-TEE running in a virtualization environment. For instance,
> > > > > > Google right now uses another way to work around RPMB
> > > > > > emulation issue when running Trusty in
> > > > > ARM Qemu:
> > > > > > https://android.googlesource.com/trusty/external/trusty/+/refs
> > > > > > /hea
> > > > > > ds/m
> > > > > > aster/test-runner/
> > > > > >
> > > > > > Virtio RPMB standardization will definitely benefit OP-TEE,
> > > > > > Google Trusty TEE, Qemu, OVMF or other modules to develop the
> > > > > > RPMB based secure storage in virtualization.
> > > > > >
> > > > >
> > > > > Is there any reason to use a new virtio-blk device, and not add
> > > > > this functionality to virtio-blk?
> > > > >
> > > > > Paolo
> > > >
> > > > RPMB does not behave as a blk device. It doesn't have block device APIs.
> > > > Current virtio blk features or definitions in spec are mostly
> > > > useless or
> > > inapplicable to virtio rpmb.
> > > > It performs a different behaviors from the operations on a blk device.
> > > > Key, writer counter or nonce are required to read/write on it.
> > > > If add it to blk device, it will not only cause to a higher
> > > > complexity, but also
> > > cause to two different behaviors on a same device.
> > > >
> > >
> > >
> > > Well it seems that current RPMB implementations are all tied to a
> > > storage device, like MMC or NVMe. Why is that and why doesn't the same
> logic apply here?
> > >
> > > --
> > > MST
> > >
> >
> > RPMB is a mandatory hardware partition of eMMC, UFS and optional for
> NVMe.
> > It is standardized by JEDEC and NVMe.
> > This partition is different from the user data partition that blk device emulates.
> > It provides a signed access in an authenticated and replay protected
> > manner that blk device does not perform. Only RPMB key owner can write
> > to it while anybody can access to a user data partition.
> 
> Sorry if I'm being dense, so how is this different from e.g. NVMe?
> 
> --
> MST

Do you refer to the difference between NVMe RPMB and eMMC RPMB?
Or between NVMe RPMB partition and NVMe user data partition?


This publicly archived list offers a means to provide input to the
OASIS Virtual I/O Device (VIRTIO) TC.

In order to verify user consent to the Feedback License terms and
to minimize spam in the list archive, subscription is required
before posting.

Subscribe: virtio-comment-subscribe@lists.oasis-open.org
Unsubscribe: virtio-comment-unsubscribe@lists.oasis-open.org
List help: virtio-comment-help@lists.oasis-open.org
List archive: https://lists.oasis-open.org/archives/virtio-comment/
Feedback License: https://www.oasis-open.org/who/ipr/feedback_license.pdf
List Guidelines: https://www.oasis-open.org/policies-guidelines/mailing-lists
Committee: https://www.oasis-open.org/committees/virtio/
Join OASIS: https://www.oasis-open.org/join/

Re: [virtio-comment] RE: [virtio-dev] Re: [virtio-comment] [PATCH] Add virtio rpmb device specification

[Michael S. Tsirkin]

On Sun, Aug 04, 2019 at 01:57:35PM +0000, Huang, Yang wrote:
> 
> 
> > -----Original Message-----
> > From: Michael S. Tsirkin [mailto:mst@redhat.com]
> > Sent: Sunday, August 4, 2019 15:49
> > To: Huang, Yang <yang.huang@intel.com>
> > Cc: Paolo Bonzini <pbonzini@redhat.com>; virtio-dev@lists.oasis-open.org;
> > virtio-comment@lists.oasis-open.org; Zhu, Bing <bing.zhu@intel.com>; Winkler,
> > Tomas <tomas.winkler@intel.com>
> > Subject: Re: [virtio-comment] RE: [virtio-dev] Re: [virtio-comment] [PATCH] Add
> > virtio rpmb device specification
> > 
> > On Sun, Aug 04, 2019 at 02:07:49AM +0000, Huang, Yang wrote:
> > >
> > >
> > > > -----Original Message-----
> > > > From: virtio-dev@lists.oasis-open.org
> > > > [mailto:virtio-dev@lists.oasis-open.org]
> > > > On Behalf Of Michael S. Tsirkin
> > > > Sent: Sunday, August 4, 2019 5:00
> > > > To: Huang, Yang <yang.huang@intel.com>
> > > > Cc: Paolo Bonzini <pbonzini@redhat.com>;
> > > > virtio-dev@lists.oasis-open.org;
> > > > virtio-comment@lists.oasis-open.org; Zhu, Bing <bing.zhu@intel.com>;
> > > > Winkler, Tomas <tomas.winkler@intel.com>
> > > > Subject: [virtio-dev] Re: [virtio-comment] [PATCH] Add virtio rpmb
> > > > device specification
> > > >
> > > > On Tue, Jul 30, 2019 at 12:33:17AM +0000, Huang, Yang wrote:
> > > > >
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: virtio-comment@lists.oasis-open.org
> > > > > > [mailto:virtio-comment@lists.oasis-
> > > > > > open.org] On Behalf Of Paolo Bonzini
> > > > > > Sent: Monday, July 29, 2019 17:19
> > > > > > To: Huang, Yang <yang.huang@intel.com>;
> > > > > > virtio-dev@lists.oasis-open.org
> > > > > > Cc: virtio-comment@lists.oasis-open.org; mst@redhat.com; Zhu,
> > > > > > Bing <bing.zhu@intel.com>; Winkler, Tomas
> > > > > > <tomas.winkler@intel.com>
> > > > > > Subject: Re: [virtio-comment] [PATCH] Add virtio rpmb device
> > > > > > specification
> > > > > >
> > > > > > On 29/07/19 09:48, Huang Yang wrote:
> > > > > > >
> > > > > > > But virtualization software like Qemu doesn't provide
> > > > > > > eMMC/UFS/NVMe RPMB emulation. It blocks the OS like Trusty or
> > > > > > > OP-TEE running in a virtualization environment. For instance,
> > > > > > > Google right now uses another way to work around RPMB
> > > > > > > emulation issue when running Trusty in
> > > > > > ARM Qemu:
> > > > > > > https://android.googlesource.com/trusty/external/trusty/+/refs
> > > > > > > /hea
> > > > > > > ds/m
> > > > > > > aster/test-runner/
> > > > > > >
> > > > > > > Virtio RPMB standardization will definitely benefit OP-TEE,
> > > > > > > Google Trusty TEE, Qemu, OVMF or other modules to develop the
> > > > > > > RPMB based secure storage in virtualization.
> > > > > > >
> > > > > >
> > > > > > Is there any reason to use a new virtio-blk device, and not add
> > > > > > this functionality to virtio-blk?
> > > > > >
> > > > > > Paolo
> > > > >
> > > > > RPMB does not behave as a blk device. It doesn't have block device APIs.
> > > > > Current virtio blk features or definitions in spec are mostly
> > > > > useless or
> > > > inapplicable to virtio rpmb.
> > > > > It performs a different behaviors from the operations on a blk device.
> > > > > Key, writer counter or nonce are required to read/write on it.
> > > > > If add it to blk device, it will not only cause to a higher
> > > > > complexity, but also
> > > > cause to two different behaviors on a same device.
> > > > >
> > > >
> > > >
> > > > Well it seems that current RPMB implementations are all tied to a
> > > > storage device, like MMC or NVMe. Why is that and why doesn't the same
> > logic apply here?
> > > >
> > > > --
> > > > MST
> > > >
> > >
> > > RPMB is a mandatory hardware partition of eMMC, UFS and optional for
> > NVMe.
> > > It is standardized by JEDEC and NVMe.
> > > This partition is different from the user data partition that blk device emulates.
> > > It provides a signed access in an authenticated and replay protected
> > > manner that blk device does not perform. Only RPMB key owner can write
> > > to it while anybody can access to a user data partition.
> > 
> > Sorry if I'm being dense, so how is this different from e.g. NVMe?
> > 
> > --
> > MST
> 
> Do you refer to the difference between NVMe RPMB and eMMC RPMB?
> Or between NVMe RPMB partition and NVMe user data partition?

I refer to the fact that NVMe and eMMC are storage devices
that support an RPMB partition. Why is virtio blk different?
wouldn't it make sense for it to support an RPMB partition?


This publicly archived list offers a means to provide input to the
OASIS Virtual I/O Device (VIRTIO) TC.

In order to verify user consent to the Feedback License terms and
to minimize spam in the list archive, subscription is required
before posting.

Subscribe: virtio-comment-subscribe@lists.oasis-open.org
Unsubscribe: virtio-comment-unsubscribe@lists.oasis-open.org
List help: virtio-comment-help@lists.oasis-open.org
List archive: https://lists.oasis-open.org/archives/virtio-comment/
Feedback License: https://www.oasis-open.org/who/ipr/feedback_license.pdf
List Guidelines: https://www.oasis-open.org/policies-guidelines/mailing-lists
Committee: https://www.oasis-open.org/committees/virtio/
Join OASIS: https://www.oasis-open.org/join/

RE: [virtio-comment] RE: [virtio-dev] Re: [virtio-comment] [PATCH] Add virtio rpmb device specification

[Huang, Yang]

> > > > > > > On 29/07/19 09:48, Huang Yang wrote:
> > > > > > > >
> > > > > > > > But virtualization software like Qemu doesn't provide
> > > > > > > > eMMC/UFS/NVMe RPMB emulation. It blocks the OS like Trusty
> > > > > > > > or OP-TEE running in a virtualization environment. For
> > > > > > > > instance, Google right now uses another way to work around
> > > > > > > > RPMB emulation issue when running Trusty in
> > > > > > > ARM Qemu:
> > > > > > > > https://android.googlesource.com/trusty/external/trusty/+/
> > > > > > > > refs
> > > > > > > > /hea
> > > > > > > > ds/m
> > > > > > > > aster/test-runner/
> > > > > > > >
> > > > > > > > Virtio RPMB standardization will definitely benefit
> > > > > > > > OP-TEE, Google Trusty TEE, Qemu, OVMF or other modules to
> > > > > > > > develop the RPMB based secure storage in virtualization.
> > > > > > > >
> > > > > > >
> > > > > > > Is there any reason to use a new virtio-blk device, and not
> > > > > > > add this functionality to virtio-blk?
> > > > > > >
> > > > > > > Paolo
> > > > > >
> > > > > > RPMB does not behave as a blk device. It doesn't have block device
> APIs.
> > > > > > Current virtio blk features or definitions in spec are mostly
> > > > > > useless or
> > > > > inapplicable to virtio rpmb.
> > > > > > It performs a different behaviors from the operations on a blk device.
> > > > > > Key, writer counter or nonce are required to read/write on it.
> > > > > > If add it to blk device, it will not only cause to a higher
> > > > > > complexity, but also
> > > > > cause to two different behaviors on a same device.
> > > > > >
> > > > >
> > > > >
> > > > > Well it seems that current RPMB implementations are all tied to
> > > > > a storage device, like MMC or NVMe. Why is that and why doesn't
> > > > > the same
> > > logic apply here?
> > > > >
> > > > > --
> > > > > MST
> > > > >
> > > >
> > > > RPMB is a mandatory hardware partition of eMMC, UFS and optional
> > > > for
> > > NVMe.
> > > > It is standardized by JEDEC and NVMe.
> > > > This partition is different from the user data partition that blk device
> emulates.
> > > > It provides a signed access in an authenticated and replay
> > > > protected manner that blk device does not perform. Only RPMB key
> > > > owner can write to it while anybody can access to a user data partition.
> > >
> > > Sorry if I'm being dense, so how is this different from e.g. NVMe?
> > >
> > > --
> > > MST
> >
> > Do you refer to the difference between NVMe RPMB and eMMC RPMB?
> > Or between NVMe RPMB partition and NVMe user data partition?
> 
> I refer to the fact that NVMe and eMMC are storage devices that support an
> RPMB partition. Why is virtio blk different?
> wouldn't it make sense for it to support an RPMB partition?

RPMB is not a blk device for the reasons:
1. It does not have blk device APIs, or is not applicable.
2. Moreover, it performs different behaviors. 
    It behaves in an authenticated and anti-replay manner, e.g. RPMB access is signed by the RPMB key, and requires a write counter.
3. For RPMB and common disks, they are hardware soldered but functions independent.

What do you think?


This publicly archived list offers a means to provide input to the
OASIS Virtual I/O Device (VIRTIO) TC.

In order to verify user consent to the Feedback License terms and
to minimize spam in the list archive, subscription is required
before posting.

Subscribe: virtio-comment-subscribe@lists.oasis-open.org
Unsubscribe: virtio-comment-unsubscribe@lists.oasis-open.org
List help: virtio-comment-help@lists.oasis-open.org
List archive: https://lists.oasis-open.org/archives/virtio-comment/
Feedback License: https://www.oasis-open.org/who/ipr/feedback_license.pdf
List Guidelines: https://www.oasis-open.org/policies-guidelines/mailing-lists
Committee: https://www.oasis-open.org/committees/virtio/
Join OASIS: https://www.oasis-open.org/join/

Re: [virtio-comment] RE: [virtio-dev] Re: [virtio-comment] [PATCH] Add virtio rpmb device specification

[Michael S. Tsirkin]

On Mon, Aug 05, 2019 at 02:39:00AM +0000, Huang, Yang wrote:
> 
> > > > > > > > On 29/07/19 09:48, Huang Yang wrote:
> > > > > > > > >
> > > > > > > > > But virtualization software like Qemu doesn't provide
> > > > > > > > > eMMC/UFS/NVMe RPMB emulation. It blocks the OS like Trusty
> > > > > > > > > or OP-TEE running in a virtualization environment. For
> > > > > > > > > instance, Google right now uses another way to work around
> > > > > > > > > RPMB emulation issue when running Trusty in
> > > > > > > > ARM Qemu:
> > > > > > > > > https://android.googlesource.com/trusty/external/trusty/+/
> > > > > > > > > refs
> > > > > > > > > /hea
> > > > > > > > > ds/m
> > > > > > > > > aster/test-runner/
> > > > > > > > >
> > > > > > > > > Virtio RPMB standardization will definitely benefit
> > > > > > > > > OP-TEE, Google Trusty TEE, Qemu, OVMF or other modules to
> > > > > > > > > develop the RPMB based secure storage in virtualization.
> > > > > > > > >
> > > > > > > >
> > > > > > > > Is there any reason to use a new virtio-blk device, and not
> > > > > > > > add this functionality to virtio-blk?
> > > > > > > >
> > > > > > > > Paolo
> > > > > > >
> > > > > > > RPMB does not behave as a blk device. It doesn't have block device
> > APIs.
> > > > > > > Current virtio blk features or definitions in spec are mostly
> > > > > > > useless or
> > > > > > inapplicable to virtio rpmb.
> > > > > > > It performs a different behaviors from the operations on a blk device.
> > > > > > > Key, writer counter or nonce are required to read/write on it.
> > > > > > > If add it to blk device, it will not only cause to a higher
> > > > > > > complexity, but also
> > > > > > cause to two different behaviors on a same device.
> > > > > > >
> > > > > >
> > > > > >
> > > > > > Well it seems that current RPMB implementations are all tied to
> > > > > > a storage device, like MMC or NVMe. Why is that and why doesn't
> > > > > > the same
> > > > logic apply here?
> > > > > >
> > > > > > --
> > > > > > MST
> > > > > >
> > > > >
> > > > > RPMB is a mandatory hardware partition of eMMC, UFS and optional
> > > > > for
> > > > NVMe.
> > > > > It is standardized by JEDEC and NVMe.
> > > > > This partition is different from the user data partition that blk device
> > emulates.
> > > > > It provides a signed access in an authenticated and replay
> > > > > protected manner that blk device does not perform. Only RPMB key
> > > > > owner can write to it while anybody can access to a user data partition.
> > > >
> > > > Sorry if I'm being dense, so how is this different from e.g. NVMe?
> > > >
> > > > --
> > > > MST
> > >
> > > Do you refer to the difference between NVMe RPMB and eMMC RPMB?
> > > Or between NVMe RPMB partition and NVMe user data partition?
> > 
> > I refer to the fact that NVMe and eMMC are storage devices that support an
> > RPMB partition. Why is virtio blk different?
> > wouldn't it make sense for it to support an RPMB partition?
> 
> RPMB is not a blk device for the reasons:
> 1. It does not have blk device APIs, or is not applicable.

That's a circular argument, isn't it?

> 2. Moreover, it performs different behaviors. 
>     It behaves in an authenticated and anti-replay manner, e.g. RPMB access is signed by the RPMB key, and requires a write counter.
> 3. For RPMB and common disks, they are hardware soldered but functions independent.
> 
> What do you think?

The question to ask is whether guests use RPMB to protect contents of a
storage device from tampering.  If yes then it makes sense as part of
the storage device it protects. for example mmc creates
a bunch of fake block devices for it - it seems likely
userspace is used to dealing with it this way.

Another question to answer is whether by adding a kernel driver
within guest you actually make guest userspace to work.


-- 
MST

This publicly archived list offers a means to provide input to the
OASIS Virtual I/O Device (VIRTIO) TC.

In order to verify user consent to the Feedback License terms and
to minimize spam in the list archive, subscription is required
before posting.

Subscribe: virtio-comment-subscribe@lists.oasis-open.org
Unsubscribe: virtio-comment-unsubscribe@lists.oasis-open.org
List help: virtio-comment-help@lists.oasis-open.org
List archive: https://lists.oasis-open.org/archives/virtio-comment/
Feedback License: https://www.oasis-open.org/who/ipr/feedback_license.pdf
List Guidelines: https://www.oasis-open.org/policies-guidelines/mailing-lists
Committee: https://www.oasis-open.org/committees/virtio/
Join OASIS: https://www.oasis-open.org/join/

RE: [virtio-comment] RE: [virtio-dev] Re: [virtio-comment] [PATCH] Add virtio rpmb device specification

[Huang, Yang]

> -----Original Message-----
> From: Michael S. Tsirkin [mailto:mst@redhat.com]
> Sent: Monday, August 5, 2019 13:57
> To: Huang, Yang <yang.huang@intel.com>
> Cc: Paolo Bonzini <pbonzini@redhat.com>; virtio-dev@lists.oasis-open.org;
> virtio-comment@lists.oasis-open.org; Zhu, Bing <bing.zhu@intel.com>; Winkler,
> Tomas <tomas.winkler@intel.com>
> Subject: Re: [virtio-comment] RE: [virtio-dev] Re: [virtio-comment] [PATCH] Add
> virtio rpmb device specification
> 
> On Mon, Aug 05, 2019 at 02:39:00AM +0000, Huang, Yang wrote:
> >
> > > > > > > > > On 29/07/19 09:48, Huang Yang wrote:
> > > > > > > > > >
> > > > > > > > > > But virtualization software like Qemu doesn't provide
> > > > > > > > > > eMMC/UFS/NVMe RPMB emulation. It blocks the OS like
> > > > > > > > > > Trusty or OP-TEE running in a virtualization
> > > > > > > > > > environment. For instance, Google right now uses
> > > > > > > > > > another way to work around RPMB emulation issue when
> > > > > > > > > > running Trusty in
> > > > > > > > > ARM Qemu:
> > > > > > > > > > https://android.googlesource.com/trusty/external/trust
> > > > > > > > > > y/+/
> > > > > > > > > > refs
> > > > > > > > > > /hea
> > > > > > > > > > ds/m
> > > > > > > > > > aster/test-runner/
> > > > > > > > > >
> > > > > > > > > > Virtio RPMB standardization will definitely benefit
> > > > > > > > > > OP-TEE, Google Trusty TEE, Qemu, OVMF or other modules
> > > > > > > > > > to develop the RPMB based secure storage in virtualization.
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > > Is there any reason to use a new virtio-blk device, and
> > > > > > > > > not add this functionality to virtio-blk?
> > > > > > > > >
> > > > > > > > > Paolo
> > > > > > > >
> > > > > > > > RPMB does not behave as a blk device. It doesn't have
> > > > > > > > block device
> > > APIs.
> > > > > > > > Current virtio blk features or definitions in spec are
> > > > > > > > mostly useless or
> > > > > > > inapplicable to virtio rpmb.
> > > > > > > > It performs a different behaviors from the operations on a blk
> device.
> > > > > > > > Key, writer counter or nonce are required to read/write on it.
> > > > > > > > If add it to blk device, it will not only cause to a
> > > > > > > > higher complexity, but also
> > > > > > > cause to two different behaviors on a same device.
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > Well it seems that current RPMB implementations are all tied
> > > > > > > to a storage device, like MMC or NVMe. Why is that and why
> > > > > > > doesn't the same
> > > > > logic apply here?
> > > > > > >
> > > > > > > --
> > > > > > > MST
> > > > > > >
> > > > > >
> > > > > > RPMB is a mandatory hardware partition of eMMC, UFS and
> > > > > > optional for
> > > > > NVMe.
> > > > > > It is standardized by JEDEC and NVMe.
> > > > > > This partition is different from the user data partition that
> > > > > > blk device
> > > emulates.
> > > > > > It provides a signed access in an authenticated and replay
> > > > > > protected manner that blk device does not perform. Only RPMB
> > > > > > key owner can write to it while anybody can access to a user data
> partition.
> > > > >
> > > > > Sorry if I'm being dense, so how is this different from e.g. NVMe?
> > > > >
> > > > > --
> > > > > MST
> > > >
> > > > Do you refer to the difference between NVMe RPMB and eMMC RPMB?
> > > > Or between NVMe RPMB partition and NVMe user data partition?
> > >
> > > I refer to the fact that NVMe and eMMC are storage devices that
> > > support an RPMB partition. Why is virtio blk different?
> > > wouldn't it make sense for it to support an RPMB partition?
> >
> > RPMB is not a blk device for the reasons:
> > 1. It does not have blk device APIs, or is not applicable.
> 
> That's a circular argument, isn't it?
> 
> > 2. Moreover, it performs different behaviors.
> >     It behaves in an authenticated and anti-replay manner, e.g. RPMB access is
> signed by the RPMB key, and requires a write counter.
> > 3. For RPMB and common disks, they are hardware soldered but functions
> independent.
> >
> > What do you think?
> 
> The question to ask is whether guests use RPMB to protect contents of a
> storage device from tampering.  If yes then it makes sense as part of the storage
> device it protects. for example mmc creates a bunch of fake block devices for it
> - it seems likely userspace is used to dealing with it this way.
> 
> Another question to answer is whether by adding a kernel driver within guest
> you actually make guest userspace to work.
> 
> 
> --
> MST

The main usage of RPMB is to protected the data stored in RPMB space from tampering.
I know there are some write protection interactions between RPMB and other partitions defined in eMMC 5.1 and UFS 3.0.
This is the only connection between RPMB and other storage space. But no plan to add it to spec at this phase.

not sure my understanding of your 2nd question is accurate. 
To protect the data storing in RPMB,
it's enough to make RPMB working for guest, by adding a virtio rpmb kernel driver.


This publicly archived list offers a means to provide input to the
OASIS Virtual I/O Device (VIRTIO) TC.

In order to verify user consent to the Feedback License terms and
to minimize spam in the list archive, subscription is required
before posting.

Subscribe: virtio-comment-subscribe@lists.oasis-open.org
Unsubscribe: virtio-comment-unsubscribe@lists.oasis-open.org
List help: virtio-comment-help@lists.oasis-open.org
List archive: https://lists.oasis-open.org/archives/virtio-comment/
Feedback License: https://www.oasis-open.org/who/ipr/feedback_license.pdf
List Guidelines: https://www.oasis-open.org/policies-guidelines/mailing-lists
Committee: https://www.oasis-open.org/committees/virtio/
Join OASIS: https://www.oasis-open.org/join/

Re: [virtio-comment] RE: [virtio-dev] Re: [virtio-comment] [PATCH] Add virtio rpmb device specification

[Michael S. Tsirkin]

On Mon, Aug 05, 2019 at 05:45:59AM +0000, Winkler, Tomas wrote:
> > On Sun, Aug 04, 2019 at 01:57:35PM +0000, Huang, Yang wrote:
> > >
> > >
> > > > -----Original Message-----
> > > > From: Michael S. Tsirkin [mailto:mst@redhat.com]
> > > > Sent: Sunday, August 4, 2019 15:49
> > > > To: Huang, Yang <yang.huang@intel.com>
> > > > Cc: Paolo Bonzini <pbonzini@redhat.com>;
> > > > virtio-dev@lists.oasis-open.org;
> > > > virtio-comment@lists.oasis-open.org; Zhu, Bing <bing.zhu@intel.com>;
> > > > Winkler, Tomas <tomas.winkler@intel.com>
> > > > Subject: Re: [virtio-comment] RE: [virtio-dev] Re: [virtio-comment]
> > > > [PATCH] Add virtio rpmb device specification
> > > >
> > > > On Sun, Aug 04, 2019 at 02:07:49AM +0000, Huang, Yang wrote:
> > > > >
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: virtio-dev@lists.oasis-open.org
> > > > > > [mailto:virtio-dev@lists.oasis-open.org]
> > > > > > On Behalf Of Michael S. Tsirkin
> > > > > > Sent: Sunday, August 4, 2019 5:00
> > > > > > To: Huang, Yang <yang.huang@intel.com>
> > > > > > Cc: Paolo Bonzini <pbonzini@redhat.com>;
> > > > > > virtio-dev@lists.oasis-open.org;
> > > > > > virtio-comment@lists.oasis-open.org; Zhu, Bing
> > > > > > <bing.zhu@intel.com>; Winkler, Tomas <tomas.winkler@intel.com>
> > > > > > Subject: [virtio-dev] Re: [virtio-comment] [PATCH] Add virtio
> > > > > > rpmb device specification
> > > > > >
> > > > > > On Tue, Jul 30, 2019 at 12:33:17AM +0000, Huang, Yang wrote:
> > > > > > >
> > > > > > >
> > > > > > > > -----Original Message-----
> > > > > > > > From: virtio-comment@lists.oasis-open.org
> > > > > > > > [mailto:virtio-comment@lists.oasis-
> > > > > > > > open.org] On Behalf Of Paolo Bonzini
> > > > > > > > Sent: Monday, July 29, 2019 17:19
> > > > > > > > To: Huang, Yang <yang.huang@intel.com>;
> > > > > > > > virtio-dev@lists.oasis-open.org
> > > > > > > > Cc: virtio-comment@lists.oasis-open.org; mst@redhat.com;
> > > > > > > > Zhu, Bing <bing.zhu@intel.com>; Winkler, Tomas
> > > > > > > > <tomas.winkler@intel.com>
> > > > > > > > Subject: Re: [virtio-comment] [PATCH] Add virtio rpmb device
> > > > > > > > specification
> > > > > > > >
> > > > > > > > On 29/07/19 09:48, Huang Yang wrote:
> > > > > > > > >
> > > > > > > > > But virtualization software like Qemu doesn't provide
> > > > > > > > > eMMC/UFS/NVMe RPMB emulation. It blocks the OS like Trusty
> > > > > > > > > or OP-TEE running in a virtualization environment. For
> > > > > > > > > instance, Google right now uses another way to work around
> > > > > > > > > RPMB emulation issue when running Trusty in
> > > > > > > > ARM Qemu:
> > > > > > > > > https://android.googlesource.com/trusty/external/trusty/+/
> > > > > > > > > refs
> > > > > > > > > /hea
> > > > > > > > > ds/m
> > > > > > > > > aster/test-runner/
> > > > > > > > >
> > > > > > > > > Virtio RPMB standardization will definitely benefit
> > > > > > > > > OP-TEE, Google Trusty TEE, Qemu, OVMF or other modules to
> > > > > > > > > develop the RPMB based secure storage in virtualization.
> > > > > > > > >
> > > > > > > >
> > > > > > > > Is there any reason to use a new virtio-blk device, and not
> > > > > > > > add this functionality to virtio-blk?
> > > > > > > >
> > > > > > > > Paolo
> > > > > > >
> > > > > > > RPMB does not behave as a blk device. It doesn't have block device
> > APIs.
> > > > > > > Current virtio blk features or definitions in spec are mostly
> > > > > > > useless or
> > > > > > inapplicable to virtio rpmb.
> > > > > > > It performs a different behaviors from the operations on a blk device.
> > > > > > > Key, writer counter or nonce are required to read/write on it.
> > > > > > > If add it to blk device, it will not only cause to a higher
> > > > > > > complexity, but also
> > > > > > cause to two different behaviors on a same device.
> > > > > > >
> > > > > >
> > > > > >
> > > > > > Well it seems that current RPMB implementations are all tied to
> > > > > > a storage device, like MMC or NVMe. Why is that and why doesn't
> > > > > > the same
> > > > logic apply here?
> > > > > >
> > > > > > --
> > > > > > MST
> > > > > >
> > > > >
> > > > > RPMB is a mandatory hardware partition of eMMC, UFS and optional
> > > > > for
> > > > NVMe.
> > > > > It is standardized by JEDEC and NVMe.
> > > > > This partition is different from the user data partition that blk device
> > emulates.
> > > > > It provides a signed access in an authenticated and replay
> > > > > protected manner that blk device does not perform. Only RPMB key
> > > > > owner can write to it while anybody can access to a user data partition.
> > > >
> > > > Sorry if I'm being dense, so how is this different from e.g. NVMe?
> > > >
> > > > --
> > > > MST
> > >
> > > Do you refer to the difference between NVMe RPMB and eMMC RPMB?
> > > Or between NVMe RPMB partition and NVMe user data partition?
> > 
> > I refer to the fact that NVMe and eMMC are storage devices that support an
> > RPMB partition. Why is virtio blk different?
> > wouldn't it make sense for it to support an RPMB partition? 
> 
> It would make sense maybe,  though RPMB is a storage but with  ordered stream-like access, it's not a block operation, so that part cannot be used.
> RPMB has also storage  configuration operation we event haven't discussed here, that may effects the whole storage device, like marking a partition read only, 
> In that case it would make sense to attach it to block device.  On other hand I think it was  a bad decision in spec that this configuration facility was added on top of RPMB.
> 
> Thanks
> Tomas

It's more of a question of what does userspace depend on?

-- 
MST

This publicly archived list offers a means to provide input to the
OASIS Virtual I/O Device (VIRTIO) TC.

In order to verify user consent to the Feedback License terms and
to minimize spam in the list archive, subscription is required
before posting.

Subscribe: virtio-comment-subscribe@lists.oasis-open.org
Unsubscribe: virtio-comment-unsubscribe@lists.oasis-open.org
List help: virtio-comment-help@lists.oasis-open.org
List archive: https://lists.oasis-open.org/archives/virtio-comment/
Feedback License: https://www.oasis-open.org/who/ipr/feedback_license.pdf
List Guidelines: https://www.oasis-open.org/policies-guidelines/mailing-lists
Committee: https://www.oasis-open.org/committees/virtio/
Join OASIS: https://www.oasis-open.org/join/