[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [virtio-dev] RE: [PATCH v3] It is a virtio based RPMB (Replay Protected Memory Block) device.
On Wed, Aug 07, 2019 at 02:36:02AM +0000, Huang, Yang wrote:
> Hi,
> I got your points on padding, SHA256, VIRTIO_RPMB_REQ_RESULT_READ etc.
> But it cannot keep compatibility with native softwares who also runs on hardware RPMB.
>
> Because RPMB frames are packed by other modules who owns RPMB key, but not by virtio driver.
> We hope a seamless usage, same APIs, same software to access RPMB under both native or virtualized env.
> The expectation is to use a same software to access RPMB by calling different drivers obeying same rules in spec.
>
>
> > > + \newline\url{https://www.nvmexpress.org/wp-content/uploads/NVM_Expre
> > > + ss_Revision_1.3.pdf}\\
> > >
> > > \end{longtable}
> > >
> >
> > At this stage I suggest we avoid nvme. Mix of LE and BE in the frame is just too
> > nasty. And ATM Linux only supports UFS/MMC.
> >
>
> Remove all contents of NVMe RPMB at this phase to simplify the spec?
Why not.
> >
> > Second, please assess the relevance of anything you copy to virtual devices.
> > Copying things like padding does not buy us anything, and just creates work
> > where we need to zero this out.
> >
> > The only thing that must match if you are passing through a hardware device is
> > the size and order of keys.
> >
> >
> >
> > > diff --git a/virtio-rpmb.tex b/virtio-rpmb.tex new file mode 100644
> > > index 0000000..c2357af
> > > --- /dev/null
> > > +++ b/virtio-rpmb.tex
> > > @@ -0,0 +1,269 @@
> > > +\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}, 12.4 of \hyperref[intro:UFS]{UFS} and
> > > +8.10 of \hyperref[intro:NVMe]{NVMe}.
> >
> >
> >
> >
> >
> >
> >
> > > +\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.
> > > +
> > > +\begin{lstlisting}
> > > +enum virtio_rpmb_type {
> > > + RPMB_TYPE_JEDEC,
> > > + RPMB_TYPE_NVME,
> >
> > enum {} has no meaning in spec. any constants must be defined.
> >
> > > +};
> > > +
> >
> > Do we have to expose the type? I think we need feature bits for various things
> > so we can split them out later.
> >
> >
> >
> > > +struct virtio_rpmb_config {
> > > + u8 capacity;
> > > + u8 max_wr_cnt;
> > > + u8 max_rd_cnt;
> > > + u8 id;
> > > + u8 type;
> > > +}
> >
> > How about adding a key programmed state here?
>
> The state here is not trusted.
> User can get this state via read counter/read/write RPMB requests.
> If the result is NOT 0007(VIRTIO_RPMB_RES_NO_AUTH_KEY), it implies it has been programmed successfully.
> And user can authenticate the result by MAC for the case key has been programmed.
>
> >
> > > +\end{lstlisting}
> >
> >
> > Why not put the counter here?
>
> Same reason. Counter here cannot be trusted.
>
> > Are all fields read-only?
>
> Yes. I will add it.
>
> > > +
> > > +\begin{description}
> > > +\item[\field{capacity}] is the capacity of the device (expressed in 128KB units).
> > > + The values MUST range between 0x00 and 0x80 inclusive for JEDEC device,
> > and
> > > + 0x00 and 0xFF inclusive for NVMe device.
> >
> > I'd just drop this. u8 so up to 0xff anyway, and I don't think any users care that
> > there are a couple of extra bytes.
> >
> > Thinking about it, 32Mbytes isn't huge at all. Why not allow larger capacity?
> >
>
> For JEDEC, the address in RPMB frame is 2Bytes. And the data[] (block size) is 256B.
> It indicates the maximum capacity is 256B * 2^16 = 16MB
> For NVMe, I think it's OK. because it's 4B address.
> >
> >
> > > +\item[\field{max_wr_cnt and max_rd_cnt}] are the maximum numbers of
> > RPMB
> > > + block count that can be performed to device in one request. 0 implies
> > > + no limitation.
> >
> > I don't understand what does block count mean in this context.
>
> It refers to the number of blocks (256B for JEDEC and 512B for NVMe) requested to be read/written.
>
> Example, if max_wr_cnt is 2 for a eMMC device, it can write RPMB with 2*256B in one request.
> It can send up to two RPMB write frames (including two data[256]) to device.
>
> > > +\item[\field{id}] is the identifier of RPMB partitions.
> >
> > What does this mean? what are the partitions? Did you mean of the device?
> >
> > I suspect what is going on is there's an actual device behind this, and this is its ID.
> > Which again begs the question whether this should just be a part of a blk or scsi
> > device.
>
> It's for multiple RPMB regions. RPMB supports up to 4 regions for UFS 3.0 or NVMe 1.3.
So a device with 1 region it's always 0?
> >
> > > +\item[\field{type}] is the rpmb type that device emulates. RPMB_TYPE_JEDEC
> > > + refers to eMMC or UFS while RPMB_TYPE_NVME refers to NVMe.
> > > +\end{description}
> >
> > Does not look like we emulate anything.
>
> Simplify by removing NVMe at current phase.
>
> > > +
> > > +\devicenormative{\subsection}{Device Initialization}{Device Types /
> > > +RPMB Device / Device Initialization}
> > > +
> > > +\begin{enumerate}
> > > +\item The virtqueue is initialized.
> > > +\item The authentication key of device MUST NOT be programmed at the
> > first device initialization.
> >
> > What is "first device initialization"? The concept does not seem to apply to
> > virtual devices. How about we just have device pre-initialized to some key? Or
> > maybe device can be in two states, key programming and operation?
>
> I will change the statement.
> Device MUST NOT pre-initialized a RPMB key.
> The only source of the key is from VIRTIO_RPMB_REQ_PROGRAM_KEY request.
> Before RPMB is programmed, read/write/read write counter will fail with 0x0007.
>
> >
> > All conformance clauses belong in conformance sections. here and elsewhere.
>
> Thanks. I will add it after the skeleton is stable.
I'd rather we try to finalize it all in one go, don't
have the time to review everything twice :)
> > > +\item The device capacity MUST be initialized to a multiple of 128Kbytes and
> > up to
> > > + 16Mbytes/32Mbytes (JEDEC/NVMe device respectively).
> > > +\end{enumerate}
> >
> > So instead of blindly copying limitations of physical devices, we can just allow
> > hypervisor to set any capacity.
>
> As mentioned above, 16MB is limited by 2B address in RPMB frame.
>
> > > +
> > > +\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}
> > > +/* 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
> > > +\end{lstlisting}
> > > +
> > > +\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 for JEDEC RPMB, and in size of 256B plus
> > > +multiple 512B for NVMe RPMB depending on the variable data size.
> >
> > Again this is just messy. Let's come up with a minimal spec.
> > See end of the message pls.
> >
> > > +
> > > +\begin{lstlisting}
> > > +struct virtio_rpmb_frame_jedec {
> > > + 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;
> > > +};
> > > +
> > > +struct virtio_rpmb_frame_nvme {
> > > + u8 stuff [191];
> > > + u8 key_mac[32];
> > > + u8 rpmb_target;
> > > + u8 nonce[16];
> > > + le32 write_counter;
> > > + le32 address;
> > > + le32 block_count;
> > > + le16 result;
> > > + le16 req_resp;
> > > + u8 data[0];
> > > +};
> >
> > Oh fun, a mix of LE and BE.
> >
> > Let's make everything consistent.
> >
> > Why do we need the "stuff" field? It helps align the size to 256 byte boundary -
> > but why do we care?
> >
> > >
> > > +
> > > +/* 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
> > > +
> > > +/* 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
> > > + authentication key. Otherwise, it's used as MAC. The MAC is calculated
> > > + using HMAC SHA-256.
> >
> > SHA-256 is pretty old. Not being a cryptographer I don't really know whether it's
> > still a good mac to use in 2019.
> >
> > Generally security considerations should probably be presented with anything
> > dealing with crypto.
> > In this case, I'd do a feature bit so we can change the crypto down the road.
> >
> >
> > > 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{rpmb_target}] is the exclusive item for NVMe device. It is
> > > + the RPMB target to access.
> >
> > There are multiple targets too?
>
> Yes.
>
> > > +
> > > +\item[\field{data}] is used to be written or read by signed access.
> >
> > What does signed access mean?
>
> It means read/write is in a authenticated way with MAC.
> I can add more descriptions.
>
> > > It's
> > > + fixed 256B for JEDEC device while variable sized payload
> > > + 512 * \field{block_count} for NVMe device.
> > > +
> > > +\item[\field{nonce}] is a random number
> >
> >
> > random how? I think it can just be anything.
>
> I will detail it.
> It used by user who request for read/read_write_counter to protect replay attack.
Oh so if one cares about replay, it needs to be hard to predict.
> >
> > > generated by user for the read or
> > > + get write counter requests and copied to the response by device.
> > > +
> > > +\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 serial number of the accessed
> > > + half sector (256B for JEDEC device) or sector (512B for NVMe device).
> >
> > serial number?
>
> Will modify it. Ignore "serial".
>
> > > +
> > > +\item[\field{block_count}] is the number of blocks (256B for JEDEC and 512B
> > > + for NVMe) requested to be read/written.
> >
> > can't this be intuited from the buffer size somehow?
> >
> > I don't really understand how can you both have block_count and a fixed size
> > data. how does this make sense?
>
> The fixed data refer to the size of one block can be read/written.
> The block count refers to how many 256 units are requested in one read/write request.
>
> Example, read request on JEDEC RPMB with two blocks (256B*2):
> User will send 3 frames, the first is the frame filled by user, with request type, address, nonce etc.
> The last 2 frames are filled by device with data, MAC, nonce, result etc.
So please map this to virtio buffers and document the mapping.
> >
> > > +
> > > +\item[\field{result}] includes information about the status of access made
> > > + to the device.
> > > +
> >
> > So I am guessing result is written by the device?
> > And type is written by the driver?
> > this does not play well with virtio where write fields are followed by read fields.
> >
> >
> > > +\item[\field{req_resp}] is the type of request or response, as defined above,
> > > + to/from the device.
> >
> > this seems to be the 1st definition. Please avoid "above" and "below", just link to
> > the definition.
>
> Thanks.
>
> > > +\end{description}
> > > +
> > > +\devicenormative{\paragraph}{Device Operation: Request Queue}{Device
> > > +Types / RPMB Device / Device Operation / Device Operation: Request
> > > +Queue}
> > > +
> > > +The device MUST parse the request from the request queue and emulate
> > > +the behaviours described in paragraph
> > > +6.6.22 of \hyperref[intro:eMMC]{eMMC}, 12.4 of \hyperref[intro:UFS]{UFS}
> > or 8.10 of \hyperref[intro:NVMe]{NVMe}:
> >
> > If you are going to emulate existing specs, then why not just emulate an existing
> > spec? Why bother with virtio at all? You gain ability to use existing drivers.
> >
> > If the reason is to make a clean abstraction, then IMHO this falls short of this
> > goal, carrying on all kind of baggage from hardware specs.
>
> Based on the different behaviors.
I think what you are saying is there's all kind of hardware and
it's useful to abstract it away?
> Or let's discuss it after the skeleton of this device is almost finalized?
>
> > > +
> > > +\begin{description}
> > > +
> > > +\item[VIRTIO_RPMB_REQ_PROGRAM_KEY] If block count has not been set to
> > 1
> > > + then VIRTIO_RPMB_RES_GENERAL_FAILURE is responded. If programming
> > of
> > > + authentication key fails then returned result is
> > VIRTIO_RPMB_RES_WRITE_FAILURE.
> > > + If some other error occurs then returned result is
> > VIRTIO_RPMB_RES_GENERAL_FAILURE.
> > > + The \field{req_resp} value VIRTIO_RPMB_RESP_PROGRAM_KEY
> > corresponds to
> > > + the key programming request.
> > > +
> > > + If VIRTIO_RPMB_REQ_RESULT_READ is requested, the device returns the
> > RPMB frame
> > > + with response (VIRTIO_RPMB_RESP_PROGRAM_KEY), the calculated MAC
> > and the result.
> >
> > I don't see what does VIRTIO_RPMB_REQ_RESULT_READ buy us.
> > I guess it proves key has been programmed - but if someone can snoop on
> > programming then for sure he has the key and won't have trouble faking the
> > mac.
> >
>
> Maybe I could add more about it. It's used by write/program_key for a returned frame.
>
> Example, write request on JEDEC RPMB with TWO blocks (256B*2):
> User will send 4 frames, the first two are the frames filled by user, with request type, counter, MAC, address, data[] etc.
> The third frame is filled with VIRTIO_RPMB_REQ_RESULT_READ request.
> And the last is for device to write with MAC, result, etc. If VIRTIO_RPMB_REQ_RESULT_READ is not requested in the 3rd frame, device will not return the result in the 4th frame.
>
> Read/read write counter does not require VIRTIO_RPMB_REQ_RESULT_READ because READ indicates a result frame by default.
>
> > > +
> > > +\item[VIRTIO_RPMB_REQ_GET_WRITE_COUNTE] If the authentication key is
> > not yet
> > > + programmed then VIRTIO_RPMB_RES_NO_AUTH_KEY is returned in
> > \field{result}.
> > > + If block count has not been set to 1 then
> > VIRTIO_RPMB_RES_GENERAL_FAILURE
> > > + SHOULD be responded.
> > > +
> > > + The device returns the RPMB frame with 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[VIRTIO_RPMB_REQ_DATA_WRITE] If the authentication key is not yet
> > programmed
> > > + then VIRTIO_RPMB_RES_NO_AUTH_KEY is returned in \field{result}. If
> > block count
> > > + is zero or greater than \field{max_wr_cnt} then
> > VIRTIO_RPMB_RES_GENERAL_FAILURE
> > > + MUST be responded. The device MUST check whether the write counter has
> > expired.
> > > + If the write counter is expired then sets the \field{result} to
> > > + VIRTIO_RPMB_RES_WRITE_COUNTER_EXPIRED. If there is an error in the
> > address
> > > + (out of range) then the \field{result} is set to
> > VIRTIO_RPMB_RES_ADDR_FAILURE.
> > > + The device MUST calculate the MAC taking authentication key and frame as
> > input,
> > > + and compares this with the MAC in the request. If the two MACâs are
> > different
> > > + then VIRTIO_RPMB_RES_AUTH_FAILURE is returned.
> > > +
> > > + If the writer counter in the request with is different from the one
> > maintained
> > > + by device then VIRTIO_RPMB_RES_COUNT_FAILURE is returned in
> > \field{result}.
> > > + If the MAC and write counter comparisons are successful then the write
> > request
> > > + is considered to be authenticated. The data from the request are written to
> > the
> > > + address indicated in the request and the write counter is incremented by 1.
> > > + If write fails then returned result is VIRTIO_RPMB_RES_WRITE_FAILURE. If
> > some
> > > + other error occurs during the write procedure then returned result is
> > > + VIRTIO_RPMB_RES_GENERAL_FAILURE.
> > > +
> > > + If VIRTIO_RPMB_REQ_RESULT_READ is requested, the device returns the
> > RPMB data
> > > + frame with response (VIRTIO_RPMB_RESP_DATA_WRITE), the incremented
> > counter value,
> > > + the data address, the calculated MAC and result.
> > > +
> > > +\item[VIRTIO_RPMB_REQ_DATA_READ] If the authentication key is not yet
> > programmed
> > > + then VIRTIO_RPMB_RES_NO_AUTH_KEY is returned in \field{result}. If
> > block count
> > > + has not been set to 1 then VIRTIO_RPMB_RES_GENERAL_FAILURE MUST be
> > responded.
> > > + If there is an error in the address (out of range) then the \field{result} is
> > > + set to VIRTIO_RPMB_RES_ADDR_FAILURE. If data fetch from addressed
> > location inside
> > > + device fails then returned result is VIRTIO_RPMB_RES_READ_FAILURE. If
> > some other
> > > + error occurs during the read procedure then returned result is
> > > + VIRTIO_RPMB_RES_GENERAL_FAILURE.
> > > +
> > > + The device returns the RPMB frame with 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[VIRTIO_RPMB_REQ_RESULT_READ] It is used following with the other
> > request
> > > + types for returned result in one or multiple RPMB frames.
> >
> > So each write request must be followed by a status request. This just seems like
> > a waste. Why not return the result immediately with the operation? Maybe UFS
> > doesn't support this but virtio sure does.
> >
> > Does device have to maintain the last request in non-volatile memory and
> > persist across resets? You do not list it as being persistent below. So I would just
> > drop this request type and have driver maintain it in guest memory.
>
> If VIRTIO_RPMB_REQ_RESULT_READ is not request for write/program_key, operation will be performed but no result returned.
> Itâs followed by write/program_key request in most cases. Device does not need to maintain it if user does not request for it.
> Keeping it for compatibility with hardware does make sense for a unified solution regardless bare metal or virtualization.
So what is wrong with driver doing it?
> > > For
> > > + VIRTIO_RPMB_REQ_PROGRAM_KEY and VIRTIO_RPMB_REQ_DATA_WRITE,
> > if block count has
> > > + not been set to 1 of VIRTIO_RPMB_REQ_RESULT_READ request, then
> > > + VIRTIO_RPMB_RES_GENERAL_FAILURE SHALL be indicated.
> > > +
> > > +\end{description}
> > > +If authetication key was programmed successfully, the device SHALL return
> > with a MAC for any operation requests.
> >
> > Lots of typos above make it pretty hard to figure out.
> >
> > > +
> > > +\drivernormative{\subsubsection}{Device Operation}{Device Types /
> > > +RPMB Device / Device Operation}
> > > +
> > > +The driver MUST configure and initialize virtqueue for the requests received.
> >
> > received where? why isn't it legal to e.g. check feature bits and then reset?
>
> Received from other modules who calls virtio rpmb driver.
> Because RPMB frames are not packed by driver.
> What driver should do is format the RPMB frames it received and for it to virtqueue, then send to device.
OK pls write this up in the spec.
> > > +
> > > +\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}, 12.4 of \hyperref[intro:UFS]{UFS}
> > > + or 8.10 of \hyperref[intro:NVMe]{NVMe}.
> > > Some elements are maintained
> > > + by the device:
> > > +\begin{enumerate}
> > > +\item The device maintains an 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 maintains 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 maintains the data for read/write via authenticated
> > > + access.
> > > +\end{enumerate}
> > > +
> >
> >
> >
> > What I have gathered from above is really just a counter and a key added to a
> > storage device.
> >
> > Key: you must have the key to write. It's programmed into the
> > device at some point by manufacturer.
> > So later, only someone who got key from manufacturer can write.
> > Data is also authenticated with the key, so if you got
> > the key from manufacturer you can verify it's valid.
> >
> > What if you didn't get the key but you steal the data
> > in transit to storage device somehow? You could
> > replay it to the device and overwrite valid data.
> > To this end device maintains write counter,
> > so you can't.
> >
> > What if you can pretend write failed, or filter out writes to pretend
> > they succeeded? First write counter will be wrong, but it's tricky for
> > applications to verify the counter: after all an application can crash.
> > So each write is followed by a response and users must validate MAC to
> > make sure write made it to the device.
> >
> >
> > On the other hand, what if again you didn't get the key but you steal
> > the read response? You could replay that to the application. To this
> > end read requests include a random value and it's copied to the
> > response. Application can put e.g. a counter there.
> >
> >
> >
> > I think we are coming back full circle and I would like to ask: so why does it not
> > make sense to add this functionality to a block device, or a scsi device? We'd get
> > lots of goodies such as multiqueue, for free.
> >
> >
> > If we implement above in a hypervisor in software, we can just ignore all
> > random hardware limitations, and support e.g. arbitrary size of writes, arbitrary
> > hash etc etc.
> >
> > So I think this is the reason you are making it a separate device and are trying to
> > support so many messy formats is because you are thinking about pass-through.
> >
> > However, I note that neither driver nor the hypervisor really care about things
> > like order of fields or endian-ness.
> > It's only the MAC calculations that are affected.
> >
> > So my suggestion is, for now just define a clean minimal interface, with some
> > kind of enumerator for an application to discover the specific MAC used. And
> > when hypervisor is forwarding the data to the device, it can move fields around,
> > swap endian-ness or whatever. Will cost some performance but it does not look
> > like this device is fast path anyway.
> >
> > And I am guessing most people do trust the hypervisor and so they will happily
> > just use a clean software implementation.
> >
>
> We can simplify the spec by supporting JEDEC only, single RPMB partition.
> But compatibility with hardware RPMB will benefit developer/user to maintain
> a same suite of RPMB APIs, structures, operations in both virtualization and bare metal.
> We can add some feature bits for extended optimization requirements.
I don't know, this picks and chooses hardware parts to copy
and I'm not sure what do you base what to emulate on.
E.g. doesn't userspace also assume RPMB is part of a storage device?
It would make sense to me if you just emulated encrypted parts.
--
MST
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]