[virtio-comment] Comments on RPMB config space chapter 5.2.14

[virtio-comment] Comments on RPMB config space chapter 5.2.14

[Harald Mommer]

Hello,

the RPMB specification chapter 5.2.14 "Device configuration layout" says 
the following:

All fields of this configuration are always available and read-only for 
the driver.

struct virtio_rpmb_config {
   u8 capacity;
   u8 max_wr_cnt;
   u8 max_rd_cnt;
}

capacity is the capacity of the device (expressed in 128KB units). The 
values MUST range between 0x00
and 0x80 inclusive.

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.

==

1.) We have an underlying physical RPMB device we would like to forward 
to a virtual machine via virtio RPMB. Looks like the physical device has 
a capacity of 256. 256 > 0x80. And 256 also does not fit in the u8 
capacity of the structure. Thinking now of cutting to 0x80 to fulfill 
the exact wording of the specification. Alternatively we might violate 
the specification and cut to 255 which is the biggest value still 
fitting in u8 capacity. But nothing of this is satisfying.

2.) Looking at the specification the maximum RPMB block count is 256. In 
our case the physical device seems to have a max_wr_cnt and max_wr_cnt 
of 1 so we actually don't have a problem here with the value range of an 
u8. But strictly speaking 256 which is still an allowed value does also 
not fit into an u8 so for a physical device allowing a block count of 
256 a cut down to 255 would have to be done. Nice is different.

It would have been better if all the u8 in the config space were le16 
not to have those value range problems now. But now it is as it is so 
I've to cut down now (still unsure which capacity limit to choose) in 
our implementation. But this is now only working around a specification 
flaw which should be addressed at some time in the specification itself.

Looking forward to get some comments on this.

Regards
Harald

-- 
Dipl.-Ing. Harald Mommer
Senior Software Engineer

OpenSynergy GmbH
Rotherstr. 20, 10245 Berlin

Phone:  +49 (30) 60 98 540-0 <== Zentrale
Fax:    +49 (30) 60 98 540-99
E-Mail: harald.mommer@opensynergy.com

www.opensynergy.com

Handelsregister: Amtsgericht Charlottenburg, HRB 108616B
Geschäftsführer/Managing Director: Regis Adjamah


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] Comments on RPMB config space chapter 5.2.14

[Huang, Yang]

 
> 1.) We have an underlying physical RPMB device we would like to forward to
> a virtual machine via virtio RPMB. Looks like the physical device has a
> capacity of 256. 256 > 0x80. And 256 also does not fit in the u8 capacity of the

256*128KB = 32MB RPMB. What's your flash, eMMC, UFS or NVMe?

> structure. Thinking now of cutting to 0x80 to fulfill the exact wording of the
> specification. Alternatively we might violate the specification and cut to 255
> which is the biggest value still fitting in u8 capacity. But nothing of this is
> satisfying.
> 
> 2.) Looking at the specification the maximum RPMB block count is 256. In our

What spec are you referring? Here is the description in eMMC Electrical Standard (5.1), JESD84-B51:
7.4.77 RPMB_SIZE_MULT [168]
The RPMB partition size is calculated from the register by using the following equation: RPMB partition
size = 128kB x RPMB_SIZE_MULT
Table 156 — RPMB Partition Size
Value Value definition
0x00 No RPMB partition available.
0x01 1 x 128Kbyte = 128Kbytes
0x02 2 x 128Kbyte = 256Kbytes
: :
0x80 128x128Kbyte = 16384Kbytes
0x81-0xFF Reserved1
NOTE 1 RPMB data frame format definition supports a maximum of 16 MB. This limits the size
of the RPMB area.

Re: [virtio-comment] Comments on RPMB config space chapter 5.2.14

[Harald Mommer]

On 11.03.22 17:02, Huang, Yang wrote:
>   
>> 1.) We have an underlying physical RPMB device we would like to forward to
>> a virtual machine via virtio RPMB. Looks like the physical device has a
>> capacity of 256. 256 > 0x80. And 256 also does not fit in the u8 capacity of the
> 256*128KB = 32MB RPMB. What's your flash, eMMC, UFS or NVMe?

UFS. I should still try to find out what exact chip is used on the board 
and try to confirm with the data sheet (if available) that the capacity 
of 256 we got from ioctl RPMB_IOC_CAP_CMD is indeed the correct one. 
Which means 32MB. just to rule out I'm not fooled by some obscure bug 
somewhere in the stack.

>> structure. Thinking now of cutting to 0x80 to fulfill the exact wording of the
>> specification. Alternatively we might violate the specification and cut to 255
>> which is the biggest value still fitting in u8 capacity. But nothing of this is
>> satisfying.
>>
>> 2.) Looking at the specification the maximum RPMB block count is 256. In our

I'm referring to the virtio specification as it is currently on latest 
master in https://github.com/oasis-tcs/virtio-spec.git.

2.) is not about the total size of the RPMB device but about the max. 
allowed number of blocks to be read or written at a time in one chunk 
(config space max_wr_cnt and max_rd_cnt). While in the text 256B is 
still a valid value in the config space this value would not fit into 
the u8. Not the issue now but remarkable when we are already in clause 
5.12.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] Comments on RPMB config space chapter 5.2.14

[Huang, Yang]

> -----Original Message-----
> From: Harald Mommer <hmo@opensynergy.com>
> Sent: Saturday, March 12, 2022 12:35 AM
> To: Huang, Yang <yang.huang@intel.com>; Alex Bennée
> <alex.bennee@linaro.org>; virtio-comment@lists.oasis-open.org
> Cc: Lukasz Zawada <Lukasz.Zawada@opensynergy.com>
> Subject: Re: [virtio-comment] Comments on RPMB config space chapter
> 5.2.14
> 
> 
> On 11.03.22 17:02, Huang, Yang wrote:
> >
> >> 1.) We have an underlying physical RPMB device we would like to
> >> forward to a virtual machine via virtio RPMB. Looks like the physical
> >> device has a capacity of 256. 256 > 0x80. And 256 also does not fit
> >> in the u8 capacity of the
> > 256*128KB = 32MB RPMB. What's your flash, eMMC, UFS or NVMe?
> 
> UFS. I should still try to find out what exact chip is used on the board and try
> to confirm with the data sheet (if available) that the capacity of 256 we got
> from ioctl RPMB_IOC_CAP_CMD is indeed the correct one.
> Which means 32MB. just to rule out I'm not fooled by some obscure bug
> somewhere in the stack.
> 
> >> structure. Thinking now of cutting to 0x80 to fulfill the exact
> >> wording of the specification. Alternatively we might violate the
> >> specification and cut to 255 which is the biggest value still fitting
> >> in u8 capacity. But nothing of this is satisfying.
> >>
> >> 2.) Looking at the specification the maximum RPMB block count is 256.
> >> In our
> 
> I'm referring to the virtio specification as it is currently on latest master in
> https://github.com/oasis-tcs/virtio-spec.git.
> 
> 2.) is not about the total size of the RPMB device but about the max.
> allowed number of blocks to be read or written at a time in one chunk (config
> space max_wr_cnt and max_rd_cnt). While in the text 256B is still a valid
> value in the config space this value would not fit into the u8. Not the issue
> now but remarkable when we are already in clause 5.12.4.
> 

Note: The normative reference of this RPMB section is based-on eMMC Spec 5.1.

Re: [virtio-comment] Comments on RPMB config space chapter 5.2.14

[Alex Bennée]

Harald Mommer <hmo@opensynergy.com> writes:

> On 11.03.22 17:02, Huang, Yang wrote:
>>   
>>> 1.) We have an underlying physical RPMB device we would like to forward to
>>> a virtual machine via virtio RPMB. Looks like the physical device has a
>>> capacity of 256. 256 > 0x80. And 256 also does not fit in the u8 capacity of the
>> 256*128KB = 32MB RPMB. What's your flash, eMMC, UFS or NVMe?
>
> UFS. I should still try to find out what exact chip is used on the
> board and try to confirm with the data sheet (if available) that the
> capacity of 256 we got from ioctl RPMB_IOC_CAP_CMD is indeed the
> correct one. Which means 32MB. just to rule out I'm not fooled by some
> obscure bug somewhere in the stack.

Which stack would this be? If it's one of my test branches I wouldn't
rule out a bug in stack, especially when it comes to handling the config
space. There hasn't been a upstream release of an RPMB driver for Linux
yet.

I'm currently in the middle of having another go that attempts to bridge
the gap between a straight dumb frame pass-through and a slightly more
ergonomic approach that none the less leaves the cryptographic frame
creation to user space.

>
>>> structure. Thinking now of cutting to 0x80 to fulfill the exact wording of the
>>> specification. Alternatively we might violate the specification and cut to 255
>>> which is the biggest value still fitting in u8 capacity. But nothing of this is
>>> satisfying.
>>>
>>> 2.) Looking at the specification the maximum RPMB block count is 256. In our
>
> I'm referring to the virtio specification as it is currently on latest
> master in https://github.com/oasis-tcs/virtio-spec.git.
>
> 2.) is not about the total size of the RPMB device but about the max.
> allowed number of blocks to be read or written at a time in one chunk
> (config space max_wr_cnt and max_rd_cnt). While in the text 256B is
> still a valid value in the config space this value would not fit into
> the u8. Not the issue now but remarkable when we are already in clause
> 5.12.4.


-- 
Alex Bennée

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/