On Thu, Mar 04, 2021 at 09:56:24PM +0100, Arnd Bergmann wrote: > 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. > Yes, for OP-TEE we have to encrypt all data going to RPMB, since the information goes via non-secure world. We get the integrity by applying the HMAC with the key that is being discussed in this thread. The TEE owns and is responsible for programming the key (and that should be something that is achieved as part of the manufacturing process). > 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 concern I have in those cases is that you need to share the RPMB key in some way if you need to access the RPMB device from secure side as well as from the non-secure side. Technically doable I guess, but in practice and in terms of security it doesn't seem like a good approach. In a shared environment like that you also have the problem that you need to agree on how to actually store files on the RPMB device. OP-TEE has it's own "FAT-look-a-like" implementation when using RPMB. But if you need mutual access, then you need to get into agreement on where to actually store the files in the RPMB. However, if secure side for some reason doesn't use RPMB at all, then kernel could of course take control of it and use it. I would probably not spend too much time on taking that use case into account until we actually see a real need for it. > > 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 -- Regards, Joakim
