Alex Bennée <alex.bennee@xxxxxxxxxx> writes: > Hi, > > This is another attempt to come up with an RPMB API for the kernel. > The last discussion of this was in the thread: Ping? Any other comments or reviews? Is there a desire to make other devices that provide RPMB functionality visible via a common API? > > 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@xxxxxxxxxx> > > 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 -- Alex Bennée
