[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [virtio-dev] [PATCH v2] Add virtio rpmb device specification
On Wed, 31 Jul 2019 14:41:56 +0000
"Huang, Yang" <yang.huang@intel.com> wrote:
> > > ---
> > > conformance.tex | 19 ++++++++++-
> > > content.tex | 3 ++
> > > virtio-rpmb.tex | 100
> > > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> > > 3 files changed, 121 insertions(+), 1 deletion(-) create mode 100644
> > > virtio-rpmb.tex
> > >
> >
> > (...)
>
> Sorry, what do you mean?
I'm just indicating that I cut some text :)
(...)
> > > +\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}
> >
> > What form do the requests that are placed on the queue take?
>
> This is defined by spec, like eMMC spec:
> https://www.jedec.org/sites/default/files/docs/JESD84-B51.pdf,
> at Chapter 6.6.22: Replay Protected Memory Block.
> It acts as req_resp of RPMB frame:
> /**
> * struct rpmb_frame_jdec - rpmb frame as defined by JDEC specs
> *
> * @stuff : stuff bytes
> * @key_mac : The authentication key or the message authentication
> * code (MAC) depending on the request/response type.
> * The MAC will be delivered in the last (or the only)
> * block of data.
> * @data : Data to be written or read by signed access.
> * @nonce : Random number generated by the host for the requests
> * and copied to the response by the RPMB engine.
> * @write_counter: Counter value for the total amount of the successful
> * authenticated data write requests made by the host.
> * @addr : Address of the data to be programmed to or read
> * from the RPMB. Address is the serial number of
> * the accessed block (half sector 256B).
> * @block_count : Number of blocks (half sectors, 256B) requested to be
> * read/programmed.
> * @result : Includes information about the status of the write counter
> * (valid, expired) and result of the access made to the RPMB.
> * @req_resp : Defines the type of request and response to/from the memory.
> */
> struct rpmb_frame_jdec {
> __u8 stuff[196];
> __u8 key_mac[32];
> __u8 data[256];
> __u8 nonce[16];
> __be32 write_counter;
> __be16 addr;
> __be16 block_count;
> __be16 result;
> __be16 req_resp;
> }
Ok, this seems to properly define the structure including endianness.
You should explicitly refer to it by name, then it should be fine (when
the document you refer to is added as a normative reference).
>
> A user should fill the rpmb frame per his request and send it to virtio rpmb driver.
> The driver then format it to virtqueue and send it to device.
Is there any formatting on top of the frame?
>
> Is it necessary to mention this rpmb frame?
Yes; otherwise, how is an implementer to know what is supposed to go on
the queue?
(...)
> > > +\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:
> >
> > If this device is supposed to simulate the behaviour of a real device, the virtio
> > spec needs to point to a specification of that behaviour as a normative
> > reference. From the information contained here, I would have no clue how to
> > actually produce a conforming device or driver implementation.
>
> I think the spec of eMMC RPMB could be a reference:
> https://www.jedec.org/sites/default/files/docs/JESD84-B51.pdf
I haven't looked at it; but from the excerpt you cited above this looks
like a good plan.
>
> > > +\begin{enumerate}
> > > +\item The device maintains an authentication key. Once the first
> > > + successful key programming is performed, the authentication
> > > + key MUST be kept unchanged during device lifecycle. It cannot
> > > + be overwritten, erased or read. This key MUST be kept regardless
> > > + of device reset or reboot.
> > > +\item The device maintains a monotonic write counter. It MUST be
> > > + initialized to zero and added by one automatically after each
> > > + successful write operation. The value cannot be reset. After
> > > + the counter has reached its maximum value 0xFFFFFFFF, it will
> > > + not be incremented anymore. This counter MUST be kept regardless
> > > + of device reset or reboot.
> > > +\item The RPMB device cannot be successfully 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 HMAC-SHA with authentication key to driver.
> > > +\item For write operation, the device MUST compare the writer counter
> > > + it receives with the one it maintained internally. If the two are
> > > + not equal, a VIRTIO_RPMB_RES_COUNT_FAILURE SHOULD be returned as
> > > + the result. The device MUST calculate the MAC using HMAC-SHA. The
> > > + authentication key acts as an input of the calculation. If the MAC
> > > + are not equal to the one it received, a VIRTIO_RPMB_RES_AUTH_FAILURE
> > > + SHOULD be returned as the result.
> > > +\item
> > > +\end{enumerate}
> >
> > I think the spec would again benefit from putting the verbose description of
> > what the driver needs to do to access the device and how the device needs to
> > react into a descriptive section, and only keep some simple normative
> > statements here.
>
> What the driver need to do is pretty simple. It just need to format the RPMB frames
> sent from user to virtqueue, and send it to device.
Yes.
> While what the device need to do is pretty complex. Besides providing RPMB spec,
> is it necessary to illustrate the behaviors of four requests that device should react?
The spec needs to be concrete enough so that it can be used as a
reference (together with the pdf you mentioned above) for implementing
a conforming device. I have not looked at the linked spec to find out
how concrete you have to get when describing the behaviours of the
requests :) Implementation details, on the other hand, do not really
belong here, only maybe as a non-normative example to make things
easier to understand.
>
> > > +
> > > +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
>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]