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
