Re: [PATCH v2 0/4] rpmb subsystem, uapi and virtio-rpmb driver

Alex Bennée
2022-04-22T14:22:43Z

Alex Bennée <alex.bennee@linaro.org> 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@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

--
Alex Bennée