[RFC,0/5] RPMB internal and user-space API + WIP virtio-rpmb frontend

Hi,

This is a follow-up to the email I sent last month:

  Subject: RPMB user space ABI
  Date: Thu, 11 Feb 2021 14:07:00 +0000
  Message-ID: <87mtwashi4.fsf@linaro.org>

which attempts to put some concrete flesh on the bones of the proposal
for a new internal kernel API for dealing with RPMB partitions and the
resultant exposed user-space character device API.

It became apparent while implementing a virtio-rpmb backend that the
initial proposed API didn't sit well with a device like virtio-rpmb
which isn't part of a greater device (like eMMC or UFS). It also
exposed the gritty details of the frame format to userspace leaving it
to deal with the complications of creating JDEC frames and calculating
MACs.

The series is based on Thomas' last posting with a bunch of
functionality dropped:

  - no FS/RPMB integration
  - dropped the simulator
  - dropped the sysfs patches

There is a start of a WIP virtio-rpmb front-end however as the initial
discussion should be focused on the proposed APIs I thought it would
be worth posting as an RFC before getting too deep into the weeds of
implementation. The principle changes to the original proposal:

  - frame construction left to device driver

  The differences between UFS/JEDEC/VirtioRPMB are left for the driver
  itself to deal with. This means things like MAC calculation and
  validation also remain the preserve of the low level implementation
  details. This doesn't mean there can't be shared code where
  implementation details are common across several device types.

  - key management uses keyctl()

  This means in theory userspace could interact with the RPMB device
  without having to manage the key itself. This also means you don't
  need to pass as much data about as the kernel internals can just use
  the keyring id with the API to fetch the key when required.

  - user-space interface split across several ioctls

  Now we no longer have multiple command frames going back and forth
  we can have a single structure per ioctl which just contains what is
  needed for the operation in question.

So what do people think? Is it worth pursuing this approach?

I'm certainly intended to complete the virtio-rpmb driver and test it
with my QEMU based vhost-user backend. However I've no direct interest
in implementing the interfaces to real hardware. I leave that to
people who have access to such things and are willing to take up the
maintainer burden if this is merged.


Alex Bennée (5):
  rpmb: add Replay Protected Memory Block (RPMB) subsystem
  char: rpmb: provide a user space interface
  tools rpmb: add RPBM access tool
  rpmb: create virtio rpmb frontend driver [WIP]
  tools/rpmb: simple test sequence

 .../userspace-api/ioctl/ioctl-number.rst      |   1 +
 MAINTAINERS                                   |   9 +
 drivers/char/Kconfig                          |   2 +
 drivers/char/Makefile                         |   1 +
 drivers/char/rpmb/Kconfig                     |  28 +
 drivers/char/rpmb/Makefile                    |   9 +
 drivers/char/rpmb/cdev.c                      | 246 +++++++
 drivers/char/rpmb/core.c                      | 431 ++++++++++++
 drivers/char/rpmb/rpmb-cdev.h                 |  17 +
 drivers/char/rpmb/virtio_rpmb.c               | 366 ++++++++++
 include/linux/rpmb.h                          | 173 +++++
 include/uapi/linux/rpmb.h                     |  68 ++
 include/uapi/linux/virtio_ids.h               |   1 +
 include/uapi/linux/virtio_rpmb.h              |  54 ++
 tools/Makefile                                |  14 +-
 tools/rpmb/.gitignore                         |   2 +
 tools/rpmb/Makefile                           |  41 ++
 tools/rpmb/key                                |   1 +
 tools/rpmb/rpmb.c                             | 649 ++++++++++++++++++
 tools/rpmb/test.sh                            |  13 +
 20 files changed, 2121 insertions(+), 5 deletions(-)
 create mode 100644 drivers/char/rpmb/Kconfig
 create mode 100644 drivers/char/rpmb/Makefile
 create mode 100644 drivers/char/rpmb/cdev.c
 create mode 100644 drivers/char/rpmb/core.c
 create mode 100644 drivers/char/rpmb/rpmb-cdev.h
 create mode 100644 drivers/char/rpmb/virtio_rpmb.c
 create mode 100644 include/linux/rpmb.h
 create mode 100644 include/uapi/linux/rpmb.h
 create mode 100644 include/uapi/linux/virtio_rpmb.h
 create mode 100644 tools/rpmb/.gitignore
 create mode 100644 tools/rpmb/Makefile
 create mode 100644 tools/rpmb/key
 create mode 100644 tools/rpmb/rpmb.c
 create mode 100755 tools/rpmb/test.sh

-- 
2.20.1

The mmc driver has some hooks to support rpmb access, but access is
mainly facilitated from user space, e.g. mmc-utils.

The ufs driver has no concept of rpmb access - it is facilitated via
user space, e.g. ufs-utils and similar.

Both for ufs and mmc, rpmb access is defined in their applicable jedec
specs. This is the case for few years now - AFAIK No new rpmb-related
stuff is expected to be introduced in the near future.

What problems, as far as mmc and ufs, are you trying to solve by this new subsystem?

Thanks,
Avri

Avri Altman <avri.altman@wdc.com> writes:

> The mmc driver has some hooks to support rpmb access, but access is
> mainly facilitated from user space, e.g. mmc-utils.
>
> The ufs driver has no concept of rpmb access - it is facilitated via
> user space, e.g. ufs-utils and similar.
>
> Both for ufs and mmc, rpmb access is defined in their applicable jedec
> specs. This is the case for few years now - AFAIK No new rpmb-related
> stuff is expected to be introduced in the near future.
>
> What problems, as far as mmc and ufs, are you trying to solve by this
> new subsystem?

Well in my case the addition of virtio-rpmb. As yet another RPMB device
which only supports RPMB transactions and isn't part of a wider block
device. The API dissonance comes into play when looking to implement it
as part of wider block device stacks and then having to do things like
fake 0 length eMMC devices with just an RPMB partition to use existing
tools.

I guess that was the original attraction of having a common kernel
subsystem to interact with RPMB functionality regardless of the
underlying HW. However from the other comments it seems the preference
is just to leave it to user-space and domain specific tools for each
device type.

>
> Thanks,
> Avri

> Avri Altman <avri.altman@wdc.com> writes:

> 

> > The mmc driver has some hooks to support rpmb access, but access is

> > mainly facilitated from user space, e.g. mmc-utils.

> >

> > The ufs driver has no concept of rpmb access - it is facilitated via

> > user space, e.g. ufs-utils and similar.

> >

> > Both for ufs and mmc, rpmb access is defined in their applicable jedec

> > specs. This is the case for few years now - AFAIK No new rpmb-related

> > stuff is expected to be introduced in the near future.

> >

> > What problems, as far as mmc and ufs, are you trying to solve by this

> > new subsystem?

> 

> Well in my case the addition of virtio-rpmb. As yet another RPMB device

> which only supports RPMB transactions and isn't part of a wider block

> device. The API dissonance comes into play when looking to implement it

> as part of wider block device stacks and then having to do things like

> fake 0 length eMMC devices with just an RPMB partition to use existing

> tools.

> 

> I guess that was the original attraction of having a common kernel

> subsystem to interact with RPMB functionality regardless of the

> underlying HW. However from the other comments it seems the preference

> is just to leave it to user-space and domain specific tools for each

> device type.

Yes.  It took us a while to clean those tools to perform by-spec rpmb access.

Anyway, I do see value in Tomas's/your approach, 
that will refrain from the need to register a designated block device.
Provided that each host is allowed to register its own ops.
Those ops can be a super-set of the various device types.
For ufs and mmc rpmb ops contains 7 operations.

Thanks,
Avri