Discussion of the VIRTIO specification
 help / color / mirror / Atom feed
From: "Alex Bennée" <alex.bennee@linaro.org>
To: Harald Mommer <hmo@opensynergy.com>
Cc: "Huang, Yang" <yang.huang@intel.com>,
	"virtio-comment@lists.oasis-open.org"
	<virtio-comment@lists.oasis-open.org>,
	Lukasz Zawada <Lukasz.Zawada@opensynergy.com>
Subject: Re: [virtio-comment] Comments on RPMB config space chapter 5.2.14
Date: Mon, 14 Mar 2022 14:05:58 +0000	[thread overview]
Message-ID: <87r17462x8.fsf@linaro.org> (raw)
In-Reply-To: <486f583a-2957-0414-5336-545bcf9b0189@opensynergy.com>


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/


      parent reply	other threads:[~2022-03-14 14:10 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
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 message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87r17462x8.fsf@linaro.org \
    --to=alex.bennee@linaro.org \
    --cc=Lukasz.Zawada@opensynergy.com \
    --cc=hmo@opensynergy.com \
    --cc=virtio-comment@lists.oasis-open.org \
    --cc=yang.huang@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox