[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID:
<DM6PR04MB65759DF9CAF6ECB5BA78E138FC222@DM6PR04MB6575.namprd04.prod.outlook.com>
Date: Tue, 5 Mar 2024 16:33:48 +0000
From: Avri Altman <Avri.Altman@....com>
To: Linus Walleij <linus.walleij@...aro.org>, Jens Wiklander
<jens.wiklander@...aro.org>
CC: "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"linux-mmc@...r.kernel.org" <linux-mmc@...r.kernel.org>,
"op-tee@...ts.trustedfirmware.org" <op-tee@...ts.trustedfirmware.org>, Shyam
Saini <shyamsaini@...ux.microsoft.com>, Ulf Hansson <ulf.hansson@...aro.org>,
Jerome Forissier <jerome.forissier@...aro.org>, Sumit Garg
<sumit.garg@...aro.org>, Ilias Apalodimas <ilias.apalodimas@...aro.org>, Bart
Van Assche <bvanassche@....org>, Randy Dunlap <rdunlap@...radead.org>, Ard
Biesheuvel <ardb@...nel.org>, Arnd Bergmann <arnd@...db.de>, Greg
Kroah-Hartman <gregkh@...uxfoundation.org>, Tomas Winkler
<tomas.winkler@...el.com>, Alex Bennée
<alex.bennee@...aro.org>
Subject: RE: [PATCH v3 1/3] rpmb: add Replay Protected Memory Block (RPMB)
subsystem
> Hi Jens,
>
> thanks for your patch!
>
> On Tue, Feb 27, 2024 at 4:31 PM Jens Wiklander <jens.wiklander@...aro.org>
> 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@...el.com>
> > Signed-off-by: Alex Bennée <alex.bennee@...aro.org>
> > Signed-off-by: Shyam Saini <shyamsaini@...ux.microsoft.com>
> > Signed-off-by: Jens Wiklander <jens.wiklander@...aro.org>
>
> 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:
Moreover, as the years went by, the differences between mmc and ufs grew:
In mmc there are 7 rpmb operations, in ufs 9.
In mmc the rpmb frame is 512Bytes, also in legacy ufs (up to including ufs3.1), but in ufs4.0 onward it can be 4k with extended header.
See e.g. https://patchwork.kernel.org/project/linux-scsi/patch/20221107131038.201724-3-beanhuo@iokpp.de/
In mmc the rpmb sequence is atomic, in ufs not.
In ufs rpmb is a wlun in mmc a partition.
Both protocols support in multi-region rpmb, but there are some differences there.
Etc.
Thanks,
Avri
> Reviewed-by: Linus Walleij <linus.walleij@...aro.org>
>
> > +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
Powered by blists - more mailing lists