> -----Original Message-----
> From: Michael S. Tsirkin [mailto:m...@redhat.com]
> Sent: Monday, August 5, 2019 13:57
> To: Huang, Yang <yang.hu...@intel.com>
> Cc: Paolo Bonzini <pbonz...@redhat.com>; virtio-dev@lists.oasis-open.org;
> virtio-comm...@lists.oasis-open.org; Zhu, Bing <bing....@intel.com>; Winkler,
> Tomas <tomas.wink...@intel.com>
> Subject: Re: [virtio-comment] RE: [virtio-dev] Re: [virtio-comment] [PATCH]
> Add
> virtio rpmb device specification
>
> On Mon, Aug 05, 2019 at 02:39:00AM +0000, Huang, Yang wrote:
> >
> > > > > > > > > On 29/07/19 09:48, Huang Yang wrote:
> > > > > > > > > >
> > > > > > > > > > But virtualization software like Qemu doesn't provide
> > > > > > > > > > eMMC/UFS/NVMe RPMB emulation. It blocks the OS like
> > > > > > > > > > Trusty or OP-TEE running in a virtualization
> > > > > > > > > > environment. For instance, Google right now uses
> > > > > > > > > > another way to work around RPMB emulation issue when
> > > > > > > > > > running Trusty in
> > > > > > > > > ARM Qemu:
> > > > > > > > > > https://android.googlesource.com/trusty/external/trust
> > > > > > > > > > y/+/
> > > > > > > > > > refs
> > > > > > > > > > /hea
> > > > > > > > > > ds/m
> > > > > > > > > > aster/test-runner/
> > > > > > > > > >
> > > > > > > > > > Virtio RPMB standardization will definitely benefit
> > > > > > > > > > OP-TEE, Google Trusty TEE, Qemu, OVMF or other modules
> > > > > > > > > > to develop the RPMB based secure storage in virtualization.
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > > Is there any reason to use a new virtio-blk device, and
> > > > > > > > > not add this functionality to virtio-blk?
> > > > > > > > >
> > > > > > > > > Paolo
> > > > > > > >
> > > > > > > > RPMB does not behave as a blk device. It doesn't have
> > > > > > > > block device
> > > APIs.
> > > > > > > > Current virtio blk features or definitions in spec are
> > > > > > > > mostly useless or
> > > > > > > inapplicable to virtio rpmb.
> > > > > > > > It performs a different behaviors from the operations on a blk
> device.
> > > > > > > > Key, writer counter or nonce are required to read/write on it.
> > > > > > > > If add it to blk device, it will not only cause to a
> > > > > > > > higher complexity, but also
> > > > > > > cause to two different behaviors on a same device.
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > Well it seems that current RPMB implementations are all tied
> > > > > > > to a storage device, like MMC or NVMe. Why is that and why
> > > > > > > doesn't the same
> > > > > logic apply here?
> > > > > > >
> > > > > > > --
> > > > > > > MST
> > > > > > >
> > > > > >
> > > > > > RPMB is a mandatory hardware partition of eMMC, UFS and
> > > > > > optional for
> > > > > NVMe.
> > > > > > It is standardized by JEDEC and NVMe.
> > > > > > This partition is different from the user data partition that
> > > > > > blk device
> > > emulates.
> > > > > > It provides a signed access in an authenticated and replay
> > > > > > protected manner that blk device does not perform. Only RPMB
> > > > > > key owner can write to it while anybody can access to a user data
> partition.
> > > > >
> > > > > Sorry if I'm being dense, so how is this different from e.g. NVMe?
> > > > >
> > > > > --
> > > > > MST
> > > >
> > > > Do you refer to the difference between NVMe RPMB and eMMC RPMB?
> > > > Or between NVMe RPMB partition and NVMe user data partition?
> > >
> > > I refer to the fact that NVMe and eMMC are storage devices that
> > > support an RPMB partition. Why is virtio blk different?
> > > wouldn't it make sense for it to support an RPMB partition?
> >
> > RPMB is not a blk device for the reasons:
> > 1. It does not have blk device APIs, or is not applicable.
>
> That's a circular argument, isn't it?
>
> > 2. Moreover, it performs different behaviors.
> > It behaves in an authenticated and anti-replay manner, e.g. RPMB access
> > is
> signed by the RPMB key, and requires a write counter.
> > 3. For RPMB and common disks, they are hardware soldered but functions
> independent.
> >
> > What do you think?
>
> The question to ask is whether guests use RPMB to protect contents of a
> storage device from tampering. If yes then it makes sense as part of the
> storage
> device it protects. for example mmc creates a bunch of fake block devices for
> it
> - it seems likely userspace is used to dealing with it this way.
>
> Another question to answer is whether by adding a kernel driver within guest
> you actually make guest userspace to work.
>
>
> --
> MST
The main usage of RPMB is to protected the data stored in RPMB space from
tampering.
I know there are some write protection interactions between RPMB and other
partitions defined in eMMC 5.1 and UFS 3.0.
This is the only connection between RPMB and other storage space. But no plan
to add it to spec at this phase.
not sure my understanding of your 2nd question is accurate.
To protect the data storing in RPMB,
it's enough to make RPMB working for guest, by adding a virtio rpmb kernel
driver.
---------------------------------------------------------------------
To unsubscribe, e-mail: virtio-dev-unsubscr...@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-h...@lists.oasis-open.org
