* [virtio-comment] Comments on RPMB config space chapter 5.2.14
@ 2022-03-11 13:49 Harald Mommer
2022-03-11 16:02 ` Huang, Yang
0 siblings, 1 reply; 5+ messages in thread
From: Harald Mommer @ 2022-03-11 13:49 UTC (permalink / raw)
To: Alex Bennée, Huang Yang, virtio-comment; +Cc: Lukasz Zawada
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/
^ permalink raw reply [flat|nested] 5+ messages in thread
* RE: [virtio-comment] Comments on RPMB config space chapter 5.2.14
2022-03-11 13:49 [virtio-comment] Comments on RPMB config space chapter 5.2.14 Harald Mommer
@ 2022-03-11 16:02 ` Huang, Yang
2022-03-11 16:34 ` Harald Mommer
0 siblings, 1 reply; 5+ messages in thread
From: Huang, Yang @ 2022-03-11 16:02 UTC (permalink / raw)
To: Harald Mommer, Alex Bennée, virtio-comment; +Cc: Lukasz Zawada
> 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.
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [virtio-comment] Comments on RPMB config space chapter 5.2.14
2022-03-11 16:02 ` Huang, Yang
@ 2022-03-11 16:34 ` Harald Mommer
2022-03-14 3:01 ` Huang, Yang
2022-03-14 14:05 ` Alex Bennée
0 siblings, 2 replies; 5+ messages in thread
From: Harald Mommer @ 2022-03-11 16:34 UTC (permalink / raw)
To: Huang, Yang, Alex Bennée, virtio-comment; +Cc: Lukasz Zawada
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/
^ permalink raw reply [flat|nested] 5+ messages in thread
* RE: [virtio-comment] Comments on RPMB config space chapter 5.2.14
2022-03-11 16:34 ` Harald Mommer
@ 2022-03-14 3:01 ` Huang, Yang
2022-03-14 14:05 ` Alex Bennée
1 sibling, 0 replies; 5+ messages in thread
From: Huang, Yang @ 2022-03-14 3:01 UTC (permalink / raw)
To: Harald Mommer, Alex Bennée, virtio-comment; +Cc: Lukasz Zawada
> -----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.
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [virtio-comment] Comments on RPMB config space chapter 5.2.14
2022-03-11 16:34 ` Harald Mommer
2022-03-14 3:01 ` Huang, Yang
@ 2022-03-14 14:05 ` Alex Bennée
1 sibling, 0 replies; 5+ messages in thread
From: Alex Bennée @ 2022-03-14 14:05 UTC (permalink / raw)
To: Harald Mommer; +Cc: Huang, Yang, virtio-comment, Lukasz Zawada
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/
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2022-03-14 14:10 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-03-11 13:49 [virtio-comment] Comments on RPMB config space chapter 5.2.14 Harald Mommer
2022-03-11 16:02 ` Huang, Yang
2022-03-11 16:34 ` Harald Mommer
2022-03-14 3:01 ` Huang, Yang
2022-03-14 14:05 ` Alex Bennée
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.