[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [virtio-comment] Request vote for the patch: Add virtio rpmb device specification
Hope you are using the ID from the experimental range meanwhile?
On Thu, Mar 05, 2020 at 01:36:38AM +0000, Huang, Yang wrote:
> Hi, Golubev
>
> For virtio rpmb in ACRN, it's in plan but with lower priority, due to other higher priority projects in hand.
> If you or community are interested, we do welcome contributions to make it aligned with the spec.
>
> Thanks.
>
>
> > -----Original Message-----
> > From: Mikhail Golubev <mikhail.golubev@opensynergy.com>
> > Sent: Thursday, March 5, 2020 12:26 AM
> > To: Huang, Yang <yang.huang@intel.com>
> > Cc: Michael S. Tsirkin <mst@redhat.com>; [email protected];
> > cohuck@redhat.com; Zhu, Bing <[email protected]>; Winkler, Tomas
> > <tomas.winkler@intel.com>; Fang, Peter <[email protected]>; Wang, Kai Z
> > <kai.z.wang@intel.com>
> > Subject: Re: [virtio-comment] Request vote for the patch: Add virtio rpmb device
> > specification
> >
> > Hi Yang!
> >
> > I was going through the latest rpmb device specification revision v6 and the
> > source code of the virtio rpmb device in the acrn-hypervsor github repo and of
> > the virtio rpmb driver in the acrn-kernel github repo. And I wonder, do you have
> > any plans to align the code with the latest specification version?
> >
> > BR,
> > Mikhail.
> >
> > On 10/31/19 3:36 AM, Huang, Yang wrote:
> > > Fixes: https://github.com/oasis-tcs/virtio-spec/issues/53
> > >
> > > Request vote at this time.
> > >
> > >
> > >> -----Original Message-----
> > >> From: Michael S. Tsirkin <mst@redhat.com>
> > >> Sent: Sunday, October 27, 2019 19:48
> > >> To: Huang, Yang <yang.huang@intel.com>
> > >> Cc: virtio-dev@lists.oasis-open.org; [email protected]; Zhu, Bing
> > >> <bing.zhu@intel.com>; Winkler, Tomas <[email protected]>; Fang,
> > >> Peter <peter.fang@intel.com>
> > >> Subject: Re: [virtio-dev] [PATCH v6] Add virtio rpmb device
> > >> specification
> > >>
> > >> On Wed, Oct 09, 2019 at 10:36:51AM +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>
> > >>>
> > >>> v5 -> v6:
> > >>> 1. Remove UFS reference, keep eMMC as the only one.
> > >>> 2. Update eMMC reference link to a free version.
> > >>> 3. Typo fixes.
> > >>> 4. Copy normative statements to the normative sections,
> > >>> and rewrite text to Device Operation section.
> > >>> 5. Update conformance.
> > >>
> > >> Looks reasonable at this point. Feel free to create a github issue
> > >> and request a vote as documented here:
> > >> https://github.com/oasis-tcs/virtio-spec/README.md
> > >> see section "use of github issues".
> > >>
> > >>> ---
> > >>> conformance.tex | 24 ++++-
> > >>> content.tex | 1 +
> > >>> introduction.tex | 3 +
> > >>> virtio-rpmb.tex | 289
> > >>> +++++++++++++++++++++++++++++++++++++++++++++++++++++++
> > >>> 4 files changed, 316 insertions(+), 1 deletion(-) create mode
> > >>> 100644 virtio-rpmb.tex
> > >>>
> > >>> diff --git a/conformance.tex b/conformance.tex index
> > >>> 0ac58aa..50969e5
> > >>> 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,20 @@ \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
> > >>> +Initialization} \item \ref{devicenormative:Device Types / RPMB
> > >>> +Device / Device Operation / Device Operation: Program Key} \item
> > >>> +\ref{devicenormative:Device Types / RPMB Device / Device Operation
> > >>> +/ Device Operation: Get Write Counter} \item
> > >>> +\ref{devicenormative:Device Types / RPMB Device / Device Operation
> > >>> +/ Device Operation: Data Write} \item \ref{devicenormative:Device
> > >>> +Types / RPMB Device / Device Operation / Device Operation: Data
> > >>> +Read} \item \ref{devicenormative:Device Types / RPMB Device /
> > >>> +Device Operation / Device Operation: Result Read} \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..2573bd5 100644
> > >>> --- a/content.tex
> > >>> +++ b/content.tex
> > >>> @@ -5677,6 +5677,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/introduction.tex b/introduction.tex index
> > >>> c96acf9..3453657 100644
> > >>> --- a/introduction.tex
> > >>> +++ b/introduction.tex
> > >>> @@ -60,6 +60,9 @@ \section{Normative References}\label{sec:Normative
> > >> References}
> > >>> \phantomsection\label{intro:SCSI MMC}\textbf{[SCSI MMC]} &
> > >>> SCSI Multimedia Commands,
> > >>>
> > >>> \newline\url{http://www.t10.org/cgi-bin/ac.pl?t=f&f=mmc6r00.pdf}\\
> > >>> + \phantomsection\label{intro:eMMC}\textbf{[eMMC]} &
> > >>> + eMMC Electrical Standard (5.1), JESD84-B51,
> > >>> +
> > >>> + \newline\url{http://www.jedec.org/sites/default/files/docs/JESD84-
> > >>> + B5
> > >>> + 1.pdf}\\
> > >>>
> > >>> \end{longtable}
> > >>>
> > >>> diff --git a/virtio-rpmb.tex b/virtio-rpmb.tex new file mode 100644
> > >>> index 0000000..9aa8c68
> > >>> --- /dev/null
> > >>> +++ b/virtio-rpmb.tex
> > >>> @@ -0,0 +1,289 @@
> > >>> +\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.
> > >>> +The device is driven via requests including read, write, get write
> > >>> +counter and program key, which are submitted via a request queue.
> > >>> +This section relies on definitions from paragraph 6.6.22 of
> > >>> +\hyperref[intro:eMMC]{eMMC}.
> > >>> +\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}
> > >>> +
> > >>> +All fields of this configuration are always available and read-only
> > >>> +for the
> > >> driver.
> > >>> +
> > >>> +\begin{lstlisting}
> > >>> +struct virtio_rpmb_config {
> > >>> + u8 capacity;
> > >>> + u8 max_wr_cnt;
> > >>> + u8 max_rd_cnt;
> > >>> +}
> > >>> +\end{lstlisting}
> > >>> +
> > >>> +\begin{description}
> > >>> +\item[\field{capacity}] is the capacity of the device (expressed in 128KB
> > units).
> > >>> + The values MUST range between 0x00 and 0x80 inclusive.
> > >>> +\item[\field{max_wr_cnt and max_rd_cnt}] are the maximum numbers of
> > >> RPMB
> > >>> + block count (256B) that can be performed to device in one
> > >>> + request. 0
> > >> implies
> > >>> + no limitation.
> > >>> +\end{description}
> > >>> +
> > >>> +\devicenormative{\subsection}{Device Initialization}{Device Types /
> > >>> +RPMB Device / Device Initialization}
> > >>> +
> > >>> +\begin{enumerate}
> > >>> +\item The virtqueue is initialized.
> > >>> +\item The device capacity MUST be initialized to a multiple of
> > >>> +128Kbytes 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 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}
> > >>> +/* RPMB Request Types */
> > >>> +#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
> > >>> +
> > >>> +/* RPMB Response Types */
> > >>> +#define VIRTIO_RPMB_RESP_PROGRAM_KEY 0x0100
> > >>> +#define VIRTIO_RPMB_RESP_GET_COUNTER 0x0200
> > >>> +#define VIRTIO_RPMB_RESP_DATA_WRITE 0x0300
> > >>> +#define VIRTIO_RPMB_RESP_DATA_READ 0x0400
> > >>> +\end{lstlisting}
> > >>> +
> > >>> +\begin{description}
> > >>> +\item[\field{VIRTIO_RPMB_REQ_PROGRAM_KEY}] requests for
> > >> authentication key programming.
> > >>> + If VIRTIO_RPMB_REQ_RESULT_READ is requested, the device returns
> > >>> +the RPMB frame with
> > >>> + the response (VIRTIO_RPMB_RESP_PROGRAM_KEY), the calculated MAC
> > >> and the result.
> > >>> +
> > >>> +\item[\field{VIRTIO_RPMB_REQ_GET_WRITE_COUNTER}] requests for
> > >> reading the write counter.
> > >>> + The device returns the RPMB frame with the response
> > >> (VIRTIO_RPMB_RESP_GET_COUNTER),
> > >>> + the writer counter, a copy of the nonce received in the request,
> > >>> + the
> > >> calculated
> > >>> + MAC and the result.
> > >>> +
> > >>> +\item[\field{VIRTIO_RPMB_REQ_DATA_WRITE}] requests for
> > >>> +authenticated
> > >> data write.
> > >>> + If VIRTIO_RPMB_REQ_RESULT_READ is requested, the device returns
> > >>> + the
> > >> RPMB data
> > >>> + frame with the response (VIRTIO_RPMB_RESP_DATA_WRITE), the
> > >> incremented counter value,
> > >>> + the data address, the calculated MAC and the result.
> > >>> +
> > >>> +\item[\field{VIRTIO_RPMB_REQ_DATA_READ}] requests for authenticated
> > >> data read.
> > >>> + The device returns the RPMB frame with the response
> > >> (VIRTIO_RPMB_RESP_DATA_READ),
> > >>> + the block count, a copy of the nonce received in the request, the address,
> > >>> + the data, the calculated MAC and the result.
> > >>> +
> > >>> +\item[\field{VIRTIO_RPMB_REQ_RESULT_READ}] requests for a returned
> > >> result.
> > >>> + It is used following with VIRTIO_RPMB_REQ_PROGRAM_KEY or
> > >> VIRTIO_RPMB_REQ_DATA_WRITE
> > >>> + request types for a returned result in one or multiple RPMB
> > >>> + frames. If it's
> > >> not
> > >>> + requested, the device will not return result frame to the driver.
> > >>> +\end{description}
> > >>> +
> > >>> +
> > >>> +\subsubsection{Device Operation: Request Queue}\label{sec:Device
> > >>> +Types / RPMB Device / Device Operation / Device Operation: Request
> > >>> +Queue}
> > >>> +
> > >>> +The request information is delivered in RPMB frame.
> > >>> +The frame is in size of 512B.
> > >>> +
> > >>> +\begin{lstlisting}
> > >>> +struct virtio_rpmb_frame {
> > >>> + u8 stuff[196];
> > >>> + u8 key_mac[32];
> > >>> + u8 data[256];
> > >>> + u8 nonce[16];
> > >>> + be32 write_counter;
> > >>> + be16 address;
> > >>> + be16 block_count;
> > >>> + be16 result;
> > >>> + be16 req_resp;
> > >>> +};
> > >>> +
> > >>> +/* RPMB Operation Results */
> > >>> +#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}
> > >>> +
> > >>> +\begin{description}
> > >>> +\item[\field{stuff}] Padding for the frame.
> > >>> +
> > >>> +\item[\field{key_mac}] is the authentication key or the message
> > >>> + authentication code (MAC) depending on the request/response type.
> > >>> + If the request is VIRTIO_RPMB_REQ_PROGRAM_KEY, it's used as an
> > >>> + authentication key. Otherwise, it's used as MAC. The MAC is calculated
> > >>> + using HMAC SHA-256. It takes as input a key and a message. The key
> > >>> + used for the MAC calculation is always the 256-bit RPMB authentication
> > >>> + key. The message used as input to the MAC calculation is the
> > >>> + concatenation of the fields in the RPMB frames excluding stuff bytes
> > >>> + and the MAC itself.
> > >>> +
> > >>> +\item[\field{data}] is used to be written or read via authenticated
> > >>> + read/write access. It's fixed 256B.
> > >>> +
> > >>> +\item[\field{nonce}] is a random number generated by the user for the
> > read
> > >>> + or get write counter requests and copied to the response by the device.
> > >>> + It's used for anti-replay protection.
> > >>> +
> > >>> +\item[\field{writer_counter}] is the counter value for the total amount of
> > >>> + the successful authenticated data write requests.
> > >>> +
> > >>> +\item[\field{address}] is the address of the data to be written to or read
> > >>> + from the RPMB virtio device. It is the number of the accessed
> > >>> + half sector (256B).
> > >>> +
> > >>> +\item[\field{block_count}] is the number of blocks (256B) requested to be
> > >>> + read/written. It's limited by \field{max_wr_cnt} or \field{max_rd_cnt}.
> > >>> + For RPMB read request, one virtio buffer including request command and
> > >>> + the subsequent [\field{block_count}] virtio buffers for response data
> > >>> + are placed in the queue.
> > >>> + For RPMB write request, [\field{block_count}] virtio buffers including
> > >>> + request command and data are placed in the queue.
> > >>> +
> > >>> +\item[\field{result}] includes information about the status of access made
> > >>> + to the device. It is written by the device.
> > >>> +
> > >>> +\item[\field{req_resp}] is the type of request or response, to/from the
> > device.
> > >>> +\end{description}
> > >>> +
> > >>> +\devicenormative{\paragraph}{Device Operation: Program Key}{Device
> > >>> +Types / RPMB Device / Device Operation / Device Operation: Program
> > >>> +Key}
> > >>> +
> > >>> +If VIRTIO_RPMB_REQ_RESULT_READ is requested, the device SHOULD
> > >>> +return the RPMB frame with the response, the calculated MAC and the
> > result:
> > >>> +
> > >>> +\begin{enumerate}
> > >>> +\item If the \field{block_count} is not set to 1 then
> > >>> + VIRTIO_RPMB_RES_GENERAL_FAILURE SHOULD be responded as
> > >> \field{result}.
> > >>> +
> > >>> +\item If the programming of authentication key fails,
> > >>> + then VIRTIO_RPMB_RES_WRITE_FAILURE SHOULD be responded as
> > >> \field{result}.
> > >>> +
> > >>> +\item If some other error occurs then returned result
> > >>> + VIRTIO_RPMB_RES_GENERAL_FAILURE SHOULD be responded as
> > >> \field{result}.
> > >>> +
> > >>> +\item The \field{req_resp} value VIRTIO_RPMB_RESP_PROGRAM_KEY
> > >> SHOULD be responded.
> > >>> +\end{enumerate}
> > >>> +
> > >>> +\devicenormative{\paragraph}{Device Operation: Get Write
> > >>> +Counter}{Device Types / RPMB Device / Device Operation / Device
> > >>> +Operation: Get Write Counter}
> > >>> +
> > >>> +If the authentication key is not yet programmed then
> > >>> +VIRTIO_RPMB_RES_NO_AUTH_KEY SHOULD be returned in \field{result}.
> > >>> +
> > >>> +If block count has not been set to 1 then
> > >>> +VIRTIO_RPMB_RES_GENERAL_FAILURE SHOULD be responded as
> > >> \field{result}.
> > >>> +
> > >>> +The \field{req_resp} value VIRTIO_RPMB_RESP_GET_COUNTER SHOULD
> > be
> > >> responded.
> > >>> +
> > >>> +\devicenormative{\paragraph}{Device Operation: Data Write}{Device
> > >>> +Types / RPMB Device / Device Operation / Device Operation: Data
> > >>> +Write}
> > >>> +
> > >>> +If VIRTIO_RPMB_REQ_RESULT_READ is requested, the device SHOULD
> > >>> +return the RPMB data frame with the response
> > >>> +VIRTIO_RPMB_RESP_DATA_WRITE, the incremented counter value, the
> > >>> +data address, the calculated MAC and the
> > >> result:
> > >>> +
> > >>> +\begin{enumerate}
> > >>> +\item If the authentication key is not yet programmed,
> > >>> + then VIRTIO_RPMB_RES_NO_AUTH_KEY SHOULD be returned in
> > >> \field{result}.
> > >>> +
> > >>> +\item If block count is zero or greater than \field{max_wr_cnt} then
> > >>> + VIRTIO_RPMB_RES_GENERAL_FAILURE SHOULD be responded.
> > >>> +
> > >>> +\item The device MUST check whether the write counter has expired.
> > >>> + If the write counter is expired then the \field{result} SHOULD be
> > >>> +set to
> > >>> + VIRTIO_RPMB_RES_WRITE_COUNTER_EXPIRED.
> > >>> +
> > >>> +\item If there is an error in the address (out of range) then the
> > >>> +\field{result}
> > >>> + SHOULD be set to VIRTIO_RPMB_RES_ADDR_FAILURE.
> > >>> +
> > >>> +\item The device MUST calculate the MAC taking authentication key
> > >>> +and frame as input,
> > >>> + and compare this with the MAC in the request. If the two MACâs
> > >>> +are different
> > >>> + then VIRTIO_RPMB_RES_AUTH_FAILURE SHOULD be returned in
> > >> \field{result}.
> > >>> +
> > >>> +\item If the writer counter in the request is different from the one
> > maintained
> > >>> + by the device then VIRTIO_RPMB_RES_COUNT_FAILURE SHOULD be
> > >> returned in \field{result}.
> > >>> +
> > >>> +\item If the MAC and write counter comparisons are matched then the
> > >>> +write
> > >> request
> > >>> + is considered to be authenticated. The data from the request
> > >>> + SHOULD be
> > >> written to the
> > >>> + address indicated in the request and the write counter SHOULD be
> > >> incremented by 1.
> > >>> +
> > >>> +\item If the write fails then the \field{result} SHOULD be
> > >> VIRTIO_RPMB_RES_WRITE_FAILURE.
> > >>> +
> > >>> +\item If some other error occurs during the writing procedure then
> > >>> +the
> > >> \field{result}
> > >>> + SHOULD be VIRTIO_RPMB_RES_GENERAL_FAILURE.
> > >>> +
> > >>> +\item The \field{req_resp} value VIRTIO_RPMB_RESP_DATA_WRITE
> > SHOULD
> > >> be responded.
> > >>> +\end{enumerate}
> > >>> +
> > >>> +\devicenormative{\paragraph}{Device Operation: Data Read}{Device
> > >>> +Types / RPMB Device / Device Operation / Device Operation: Data
> > >>> +Read}
> > >>> +
> > >>> +If the authentication key is not yet programmed then
> > >>> +VIRTIO_RPMB_RES_NO_AUTH_KEY SHOULD be returned in \field{result}.
> > >>> +
> > >>> +If block count has not been set to 1 then
> > >>> +VIRTIO_RPMB_RES_GENERAL_FAILURE SHOULD be responded as
> > >> \field{result}.
> > >>> +
> > >>> +If there is an error in the address (out of range) then the
> > >>> +\field{result} SHOULD be set to VIRTIO_RPMB_RES_ADDR_FAILURE.
> > >>> +
> > >>> +If data fetch from addressed location inside the device fails then
> > >>> +the \field{result} SHOULD be VIRTIO_RPMB_RES_READ_FAILURE.
> > >>> +
> > >>> +If some other error occurs during the read procedure then the
> > >>> +\field{result} SHOULD be VIRTIO_RPMB_RES_GENERAL_FAILURE.
> > >>> +
> > >>> +The \field{req_resp} value VIRTIO_RPMB_RESP_DATA_READ SHOULD be
> > >> responded.
> > >>> +
> > >>> +\devicenormative{\paragraph}{Device Operation: Result Read}{Device
> > >>> +Types / RPMB Device / Device Operation / Device Operation: Result
> > >>> +Read}
> > >>> +
> > >>> +If the \field{block_count} has not been set to 1 of
> > >>> +VIRTIO_RPMB_REQ_RESULT_READ request then
> > >> VIRTIO_RPMB_RES_GENERAL_FAILURE SHOULD be responded as
> > \field{result}.
> > >>> +
> > >>> +\drivernormative{\subsubsection}{Device Operation}{Device Types /
> > >>> +RPMB Device / Device Operation}
> > >>> +
> > >>> +The RPMB frames MUST not be packed by the driver.
> > >>> +The driver MUST configure, initialize and format virtqueue for the
> > >>> +RPMB
> > >> requests received from its caller then send it to the device.
> > >>> +
> > >>> +\devicenormative{\subsubsection}{Device Operation}{Device Types /
> > >>> +RPMB Device / Device Operation}
> > >>> +
> > >>> +The virtio-rpmb device could be backed in a number of ways. It SHOULD
> > >>> + keep consistent behaviors with hardware as described in paragraph
> > >>> + 6.6.22 of \hyperref[intro:eMMC]{eMMC}.
> > >>> + Some elements are maintained by the device:
> > >>> +\begin{enumerate}
> > >>> +\item The device MUST maintain a one-time programmable
> > >>> +authentication
> > >> key.
> > >>> + It cannot be overwritten, erased or read. The key is used to
> > >>> + authenticate the accesses when MAC is calculated. This key MUST be
> > >>> + kept regardless of device reset or reboot.
> > >>> +\item The device MUST maintain a read-only monotonic write counter.
> > >>> +It
> > >>> + MUST be initialized to zero and added by one automatically along with
> > >>> + successful write operation. The value cannot be reset. After
> > >>> + the counter has reached its maximum value 0xFFFF FFFF, it will
> > >>> + not be incremented anymore. This counter MUST be kept regardless
> > >>> + of device reset or reboot.
> > >>> +\item The device MUST maintain the data for read/write via authenticated
> > >>> + access.
> > >>> +\end{enumerate}
> > >>> +
> > >>> --
> > >>> 2.7.4
> > >>>
> > >>>
> > >>> --------------------------------------------------------------------
> > >>> - To unsubscribe, e-mail:
> > >>> virtio-dev-unsubscribe@lists.oasis-open.org
> > >>> For additional commands, e-mail:
> > >>> virtio-dev-help@lists.oasis-open.org
> >
> > --
> > Mikhail Golubev
> > Senior Software Engineer
> >
> > OpenSynergy GmbH
> > Rotherstr. 20, 10245 Berlin
> >
> > Telefon: +49 (30) 60 98 54 0 - 903
> > EMail: mikhail.golubev@opensynergy.com
> >
> > www.opensynergy.com
> >
> > Handelsregister/Commercial Registry: Amtsgericht Charlottenburg, HRB
> > 108616B GeschÃftsfÃhrer/Managing Director: Regis Adjamah
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]