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

[Alex BennÃe <alex.bennee@linaro.org>]

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