On Wed, Mar 3, 2021 at 2:54 PM Alex Bennée <alex.bennee@xxxxxxxxxx> wrote: > > A number of storage technologies support a specialised hardware > partition designed to be resistant to replay attacks. The underlying > HW protocols differ but the operations are common. The RPMB partition > cannot be accessed via standard block layer, but by a set of specific > commands: WRITE, READ, GET_WRITE_COUNTER, and PROGRAM_KEY. Such a > partition provides authenticated and replay protected access, hence > suitable as a secure storage. > > The RPMB layer aims to provide in-kernel API for Trusted Execution > Environment (TEE) devices that are capable to securely compute block > frame signature. In case a TEE device wishes to store a replay > protected data, requests the storage device via RPMB layer to store > the data. > > A TEE device driver can claim the RPMB interface, for example, via > class_interface_register(). The RPMB layer provides a series of > operations for interacting with the device. > > * program_key - a one time operation for setting up a new device > * get_capacity - introspect the device capacity > * get_write_count - check the write counter > * write_blocks - write a series of blocks to the RPMB device > * read_blocks - read a series of blocks from the RPMB device Based on the discussion we had today in a meeting, it seems the main change that is needed is to get back to the original model of passing the encrypted data to the kernel instead of cleartext data, as the main use case we know of is to have the key inside of the TEE device and not available to the kernel or user space. This is also required to be able to forward the encrypted data through the same interface on a KVM host, when the guest uses virtio-rpmb, and the host forwards the data into an mmc or ufs device. That said, I can also imagine use cases where we do want to store the key in the kernel's keyring, so maybe we end up needing both. > The detailed operation of implementing the access is left to the TEE > device driver itself. > > [This is based-on Thomas Winkler's proposed API from: > > https://lore.kernel.org/linux-mmc/1478548394-8184-2-git-send-email-tomas.winkler@xxxxxxxxx/ > > The principle difference is the framing details and HW specific > bits (JDEC vs NVME frames) are left to the lower level TEE driver to > worry about. The eventual userspace ioctl interface will aim to be > similarly generic. This is an RFC to follow up on: > > Subject: RPMB user space ABI > Date: Thu, 11 Feb 2021 14:07:00 +0000 > Message-ID: <87mtwashi4.fsf@xxxxxxxxxx>] > > Signed-off-by: Alex Bennée <alex.bennee@xxxxxxxxxx> > Cc: Tomas Winkler <tomas.winkler@xxxxxxxxx> > Cc: Ulf Hansson <ulf.hansson@xxxxxxxxxx> > Cc: Linus Walleij <linus.walleij@xxxxxxxxxx> > Cc: Arnd Bergmann <arnd.bergmann@xxxxxxxxxx> > Cc: Ilias Apalodimas <ilias.apalodimas@xxxxxxxxxx> > --- > MAINTAINERS | 7 + > drivers/char/Kconfig | 2 + > drivers/char/Makefile | 1 + > drivers/char/rpmb/Kconfig | 11 + > drivers/char/rpmb/Makefile | 7 + > drivers/char/rpmb/core.c | 429 +++++++++++++++++++++++++++++++++++++ > include/linux/rpmb.h | 163 ++++++++++++++ My feeling is that it should be a top-level subsystem, in drivers/rpmb rather than drivers/char/rpmb, as you implement an abstraction layer that other drivers can plug into, rather than a simple driver. Arnd
