> 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? I believe I've sent the implementation for all the backends, need to search the mailing list.
