Re: [virtio-comment] RE: [virtio-dev] Re: [virtio-comment] [PATCH] Add virtio rpmb device specification

["Michael S. Tsirkin" <mst@redhat.com>]

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/trusty/+/
> > > > > > > > > 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

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/