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

From: Alex Bennée
Date: Wed Mar 03 2021 - 12:50:09 EST


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@xxxxxxxxxx>

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