Hi Jens, thanks for your patch! On Tue, Feb 27, 2024 at 4:31 PM Jens Wiklander <jens.wiklander@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 > RPMB 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 initial aim of this patch is to provide a simple RPMB driver > interface which can be accessed by the optee driver to facilitate early > RPMB access to OP-TEE OS (secure OS) during the boot time. > > A TEE device driver can claim the RPMB interface, for example, via > rpmb_interface_register() or rpmb_dev_find_device(). The RPMB driver > provides a callback to route RPMB frames to the RPMB device accessible > via rpmb_route_frames(). > > The detailed operation of implementing the access is left to the TEE > device driver itself. > > Signed-off-by: Tomas Winkler <tomas.winkler@xxxxxxxxx> > Signed-off-by: Alex Bennée <alex.bennee@xxxxxxxxxx> > Signed-off-by: Shyam Saini <shyamsaini@xxxxxxxxxxxxxxxxxxx> > Signed-off-by: Jens Wiklander <jens.wiklander@xxxxxxxxxx> I would mention in the commit that the subsystem is currently only used with eMMC but is designed to be used also by UFS and NVME. Nevertheless, no big deal so: Reviewed-by: Linus Walleij <linus.walleij@xxxxxxxxxx> > +config RPMB > + tristate "RPMB partition interface" > + depends on MMC depends on MMC || SCSI_UFSHCD || NVME_CORE ? Or do we want to hold it off until we implement the backends? Yours, Linus Walleij
