All of lore.kernel.org
 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 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.