lkml.org 
[lkml]   [2022]   [Apr]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Subject[PATCH v2 0/4] rpmb subsystem, uapi and virtio-rpmb driver
Date
Hi,

This is another attempt to come up with an RPMB API for the kernel.
The last discussion of this was in the thread:

Subject: [RFC PATCH 0/5] RPMB internal and user-space API + WIP virtio-rpmb frontend
Date: Wed, 3 Mar 2021 13:54:55 +0000
Message-Id: <20210303135500.24673-1-alex.bennee@linaro.org>

The series provides for the RPMB sub-system, a new chardev API driven
by ioctls and a full multi-block capable virtio-rpmb driver. You can
find a working vhost-user backend in my QEMU branch here:

https://github.com/stsquad/qemu/commits/virtio/vhost-user-rpmb-v2

The branch is a little messy but I'll be posting a cleaned up version
in the following weeks. The only real changes to the backend is the
multi-block awareness and some tweaks to deal with QEMU internals
handling VirtIO config space messages which weren't previously
exercised. The test.sh script in tools/rpmb works through the various
transactions but isn't comprehensive.

Changes since the last posting:

- frame construction is mostly back in userspace

The previous discussion showed there wasn't any appetite for using
the kernels keyctl() interface so userspace yet again takes
responsibility for constructing most* frames. Currently these are
all pure virtio-rpmb frames but the code is written so we can plug
in additional frame types. The virtio-rpmb driver does some
validation and in some cases (* read-blocks) constructs the request
frame in the driver. It would take someone implementing a driver for
another RPMB device type to see if this makes sense.

- user-space interface is still split across several ioctls

Although 3 of the ioctls share the common rpmb_ioc_reqresp_cmd
structure it does mean things like capacity, write_count and
read_blocks can have their own structure associated with the
command.

As before I shall follow up with the QEMU based vhost-user backend and
hopefully a rust-vmm re-implementation. 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.

Regards,

Alex


Alex Bennée (4):
rpmb: add Replay Protected Memory Block (RPMB) subsystem
char: rpmb: provide a user space interface
rpmb: create virtio rpmb frontend driver
tools rpmb: add RPBM access tool

.../userspace-api/ioctl/ioctl-number.rst | 1 +
MAINTAINERS | 9 +
drivers/Kconfig | 2 +
drivers/Makefile | 1 +
drivers/rpmb/Kconfig | 28 +
drivers/rpmb/Makefile | 9 +
drivers/rpmb/cdev.c | 309 +++++
drivers/rpmb/core.c | 439 +++++++
drivers/rpmb/rpmb-cdev.h | 17 +
drivers/rpmb/virtio_rpmb.c | 518 ++++++++
include/linux/rpmb.h | 182 +++
include/uapi/linux/rpmb.h | 99 ++
include/uapi/linux/virtio_rpmb.h | 54 +
tools/Makefile | 16 +-
tools/rpmb/.gitignore | 2 +
tools/rpmb/Makefile | 41 +
tools/rpmb/key | 1 +
tools/rpmb/rpmb.c | 1083 +++++++++++++++++
tools/rpmb/test.sh | 22 +
19 files changed, 2828 insertions(+), 5 deletions(-)
create mode 100644 drivers/rpmb/Kconfig
create mode 100644 drivers/rpmb/Makefile
create mode 100644 drivers/rpmb/cdev.c
create mode 100644 drivers/rpmb/core.c
create mode 100644 drivers/rpmb/rpmb-cdev.h
create mode 100644 drivers/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.30.2

\
 
 \ /
  Last update: 2022-04-06 01:47    [W:0.207 / U:0.448 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site