From: "Alex Bennée" <alex.bennee@linaro.org>
To: linux-kernel@vger.kernel.org
Cc: maxim.uvarov@linaro.org, joakim.bech@linaro.org,
ilias.apalodimas@linaro.org, arnd@linaro.org,
ruchika.gupta@linaro.org, tomas.winkler@intel.com,
yang.huang@intel.com, bing.zhu@intel.com,
Matti.Moell@opensynergy.com, hmo@opensynergy.com,
linux-mmc@vger.kernel.org, linux-scsi@vger.kernel.org,
linux-nvme@vger.kernel.org,
"Alex Bennée" <alex.bennee@linaro.org>
Subject: [RFC PATCH 0/5] RPMB internal and user-space API + WIP virtio-rpmb frontend
Date: Wed, 3 Mar 2021 13:54:55 +0000 [thread overview]
Message-ID: <20210303135500.24673-1-alex.bennee@linaro.org> (raw)
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@linaro.org>
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
next reply other threads:[~2021-03-03 18:11 UTC|newest]
Thread overview: 47+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-03-03 13:54 Alex Bennée [this message]
2021-03-03 13:54 ` [RFC PATCH 1/5] rpmb: add Replay Protected Memory Block (RPMB) subsystem Alex Bennée
2021-03-03 15:28 ` Ulf Hansson
2021-03-03 19:37 ` Alex Bennée
2021-03-04 20:56 ` Arnd Bergmann
2021-03-05 7:51 ` Joakim Bech
2021-03-05 8:44 ` Arnd Bergmann
2021-03-08 16:20 ` Linus Walleij
2021-03-09 21:09 ` Hector Martin
2021-03-10 5:14 ` Sumit Garg
2021-03-10 8:47 ` Hector Martin
2021-03-10 9:48 ` Linus Walleij
2021-03-10 13:52 ` Hector Martin
2021-03-11 0:36 ` Linus Walleij
2021-03-11 9:22 ` Hector Martin
2021-03-11 14:06 ` Linus Walleij
2021-03-11 20:02 ` Hector Martin
2021-03-12 9:22 ` Linus Walleij
2021-03-10 10:29 ` Sumit Garg
2021-03-11 0:49 ` Linus Walleij
2021-03-11 1:07 ` James Bottomley
2021-03-11 9:45 ` Hector Martin
2021-03-11 14:31 ` Linus Walleij
2021-03-11 20:29 ` Hector Martin
2021-03-11 20:57 ` Alex Bennée
2021-03-12 10:00 ` Linus Walleij
2021-03-12 9:47 ` Linus Walleij
2021-03-12 11:59 ` Sumit Garg
2021-03-12 12:08 ` Ilias Apalodimas
2021-03-09 17:12 ` David Howells
2021-03-10 4:54 ` Sumit Garg
2021-03-10 9:33 ` Linus Walleij
2021-03-03 13:54 ` [RFC PATCH 2/5] char: rpmb: provide a user space interface Alex Bennée
2021-03-04 7:01 ` Winkler, Tomas
2021-03-04 10:19 ` Alex Bennée
2021-03-04 10:34 ` Winkler, Tomas
2021-03-04 17:52 ` Alex Bennée
2021-03-04 19:54 ` Winkler, Tomas
2021-03-04 21:43 ` Arnd Bergmann
2021-03-05 6:31 ` Winkler, Tomas
2021-03-04 21:08 ` Arnd Bergmann
2021-03-03 13:54 ` [RFC PATCH 3/5] tools rpmb: add RPBM access tool Alex Bennée
2021-03-03 13:54 ` [RFC PATCH 4/5] rpmb: create virtio rpmb frontend driver [WIP] Alex Bennée
2021-03-03 13:55 ` [RFC PATCH 5/5] tools/rpmb: simple test sequence Alex Bennée
2021-03-09 13:27 ` [RFC PATCH 0/5] RPMB internal and user-space API + WIP virtio-rpmb frontend Avri Altman
2021-03-10 14:29 ` Alex Bennée
2021-03-11 13:45 ` Avri Altman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20210303135500.24673-1-alex.bennee@linaro.org \
--to=alex.bennee@linaro.org \
--cc=Matti.Moell@opensynergy.com \
--cc=arnd@linaro.org \
--cc=bing.zhu@intel.com \
--cc=hmo@opensynergy.com \
--cc=ilias.apalodimas@linaro.org \
--cc=joakim.bech@linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mmc@vger.kernel.org \
--cc=linux-nvme@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
--cc=maxim.uvarov@linaro.org \
--cc=ruchika.gupta@linaro.org \
--cc=tomas.winkler@intel.com \
--cc=yang.huang@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).