All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Alex Bennée" <alex.bennee@linaro.org>
To: Cornelia Huck <cohuck@redhat.com>
Cc: virtio-comment@lists.oasis-open.org,
	Manos  Pitsidianakis <manos.pitsidianakis@linaro.org>,
	Harald Mommer <hmo@opensynergy.com>,
	Will Deacon <will@kernel.org>
Subject: Re: [virtio-comment] [RFC PATCH] virtio-rpmb: fix spec land mine in max_[wr|rd]_cnt
Date: Thu, 22 Jun 2023 14:16:24 +0100	[thread overview]
Message-ID: <87zg4rfx2u.fsf@linaro.org> (raw)
In-Reply-To: <87v8fh17sj.fsf@redhat.com>


Cornelia Huck <cohuck@redhat.com> writes:

> On Mon, Jun 19 2023, Alex Bennée <alex.bennee@linaro.org> wrote:
>
>> Even if 0 meant no limit we are still limited by the field size of the
>> request. That said for a maximum sized partition (* 80 128 1024) you
>> could only actually request 40960 blocks before running out of device.
>> Perhaps it would be better to mark 0 as invalid?
>
> I don't think we can mark 0 as invalid, as it has been in a published
> spec and implementations may be already using it.

Certainly no open source implementations as this was pointed out in a
code review for a kernel driver implementation. But yes there may be
other virtio-rpmb in the field we don't know about.

Current feedback though is there are some difficulties integrating
virtio-rpmb into driver stacks which are designed around accessing RPMB
partitions on exiting storage devices.

I'm not sure how much virtio-rpmb should be adapted to more easily fit
into driver stacks though - there was lukewarm interest in integrating a
common RPMB kernel char based user-space API which doesn't need to
involve the block devices. However more likely consumers of virtio-rpmb
are going to be secure firmwares and early boot code.

> That said, what is the actual limitation? Knowing nothing about RPMB, is
> it 64k (what can fit in block_count), or the 40960 you mentioned above
> as a value defined by other reasons (maximum size of a partition -- I
> assume that cannot change?)

Yes, just above we state:

  \item[\field{capacity}] is the capacity of the device (expressed in 128KB units).
     The values MUST range between 0x00 and 0x80 inclusive.

that said the capacity field has space for a bit more although it itself
is only 8 bit as well.

>
>>
>> Cc: Manos Pitsidianakis <manos.pitsidianakis@linaro.org>
>> Cc: Harald Mommer <hmo@opensynergy.com>
>> Cc: Will Deacon <will@kernel.org>
>> Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
>> ---
>>  device-types/rpmb/description.tex | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/device-types/rpmb/description.tex b/device-types/rpmb/description.tex
>> index 1dae3fd..2ce8a5b 100644
>> --- a/device-types/rpmb/description.tex
>> +++ b/device-types/rpmb/description.tex
>> @@ -37,7 +37,7 @@ \subsection{Device configuration layout}\label{sec:Device Types / RPMB Device /
>>     The values MUST range between 0x00 and 0x80 inclusive.
>>  \item[\field{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.
>> +   no limitation other than the maximum value you can store in \field{block_count} (65535).
>
> So, I'm now wondering what these fields actually refer to. They are u8,
> so obviously less than what fits into be16... are reads/writes limited
> by anything else?
>
>>  \end{description}
>>  
>>  \devicenormative{\subsection}{Device Initialization}{Device Types / RPMB Device / Device Initialization}


-- 
Alex Bennée
Virtualisation Tech Lead @ Linaro

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/


  reply	other threads:[~2023-06-22 13:25 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-06-19 12:01 [virtio-comment] [RFC PATCH] virtio-rpmb: fix spec land mine in max_[wr|rd]_cnt Alex Bennée
2023-06-21  9:30 ` Cornelia Huck
2023-06-22 13:16   ` Alex Bennée [this message]
2023-06-26 19:05 ` Harald Mommer
2023-06-26 20:03   ` Alex Bennée

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=87zg4rfx2u.fsf@linaro.org \
    --to=alex.bennee@linaro.org \
    --cc=cohuck@redhat.com \
    --cc=hmo@opensynergy.com \
    --cc=manos.pitsidianakis@linaro.org \
    --cc=virtio-comment@lists.oasis-open.org \
    --cc=will@kernel.org \
    /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.