From: Manuel Traut <manut@mecka.net>
To: Jens Wiklander <jens.wiklander@linaro.org>
Cc: linux-kernel@vger.kernel.org, linux-mmc@vger.kernel.org,
op-tee@lists.trustedfirmware.org,
Shyam Saini <shyamsaini@linux.microsoft.com>,
Ulf Hansson <ulf.hansson@linaro.org>,
Linus Walleij <linus.walleij@linaro.org>,
Jerome Forissier <jerome.forissier@linaro.org>,
Sumit Garg <sumit.garg@linaro.org>,
Ilias Apalodimas <ilias.apalodimas@linaro.org>,
Bart Van Assche <bvanassche@acm.org>,
Randy Dunlap <rdunlap@infradead.org>,
Ard Biesheuvel <ardb@kernel.org>, Arnd Bergmann <arnd@arndb.de>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Tomas Winkler <tomas.winkler@intel.com>,
Alexander Usyskin <alexander.usyskin@intel.com>
Subject: Re: [PATCH v5 2/3] mmc: block: register RPMB partition with the RPMB subsystem
Date: Mon, 29 Apr 2024 11:40:59 +0200 [thread overview]
Message-ID: <Zi9rKzz8u8z7cIy0@mecka.net> (raw)
In-Reply-To: <CAHUa44Fojanryuc+ciJrVZUopRLcTt2teS_pC4BBjt1Wmy240A@mail.gmail.com>
On Fri, Apr 26, 2024 at 03:24:21PM +0200, Jens Wiklander wrote:
> On Thu, Apr 25, 2024 at 10:43 AM Manuel Traut <manut@mecka.net> wrote:
> >
> > On Mon, Apr 22, 2024 at 11:19:35AM +0200, Jens Wiklander wrote:
> > > Register eMMC RPMB partition with the RPMB subsystem and provide
> > > an implementation for the RPMB access operations abstracting
> > > the actual multi step process.
> > >
> > > Add a callback to extract the needed device information at registration
> > > to avoid accessing the struct mmc_card at a later stage as we're not
> > > holding a reference counter for this struct.
> > >
> > > Taking the needed reference to md->disk in mmc_blk_alloc_rpmb_part()
> > > instead of in mmc_rpmb_chrdev_open(). This is needed by the
> > > route_frames() function pointer in struct rpmb_ops.
> > >
> > > Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
> > > Signed-off-by: Alexander Usyskin <alexander.usyskin@intel.com>
> > > Signed-off-by: Jens Wiklander <jens.wiklander@linaro.org>
> > > ---
> > > drivers/mmc/core/block.c | 241 ++++++++++++++++++++++++++++++++++++++-
> > > 1 file changed, 239 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/drivers/mmc/core/block.c b/drivers/mmc/core/block.c
> > > index 32d49100dff5..a7f126fbc605 100644
> > > --- a/drivers/mmc/core/block.c
> > > +++ b/drivers/mmc/core/block.c
> > > @@ -33,6 +33,7 @@
> > > #include <linux/cdev.h>
> > > #include <linux/mutex.h>
> > > #include <linux/scatterlist.h>
> > > +#include <linux/string.h>
> > > #include <linux/string_helpers.h>
> > > #include <linux/delay.h>
> > > #include <linux/capability.h>
> > > @@ -40,6 +41,7 @@
> > > #include <linux/pm_runtime.h>
> > > #include <linux/idr.h>
> > > #include <linux/debugfs.h>
> > > +#include <linux/rpmb.h>
> > >
> > > #include <linux/mmc/ioctl.h>
> > > #include <linux/mmc/card.h>
> > > @@ -76,6 +78,48 @@ MODULE_ALIAS("mmc:block");
> > > #define MMC_EXTRACT_INDEX_FROM_ARG(x) ((x & 0x00FF0000) >> 16)
> > > #define MMC_EXTRACT_VALUE_FROM_ARG(x) ((x & 0x0000FF00) >> 8)
> > >
> > > +/**
> > > + * struct rpmb_frame - rpmb frame as defined by eMMC 5.1 (JESD84-B51)
> > > + *
> > > + * @stuff : stuff bytes
> > > + * @key_mac : The authentication key or the message authentication
> > > + * code (MAC) depending on the request/response type.
> > > + * The MAC will be delivered in the last (or the only)
> > > + * block of data.
> > > + * @data : Data to be written or read by signed access.
> > > + * @nonce : Random number generated by the host for the requests
> > > + * and copied to the response by the RPMB engine.
> > > + * @write_counter: Counter value for the total amount of the successful
> > > + * authenticated data write requests made by the host.
> > > + * @addr : Address of the data to be programmed to or read
> > > + * from the RPMB. Address is the serial number of
> > > + * the accessed block (half sector 256B).
> > > + * @block_count : Number of blocks (half sectors, 256B) requested to be
> > > + * read/programmed.
> > > + * @result : Includes information about the status of the write counter
> > > + * (valid, expired) and result of the access made to the RPMB.
> > > + * @req_resp : Defines the type of request and response to/from the memory.
> > > + *
> > > + * The stuff bytes and big-endian properties are modeled to fit to the spec.
> > > + */
> > > +struct rpmb_frame {
> > > + u8 stuff[196];
> > > + u8 key_mac[32];
> > > + u8 data[256];
> > > + u8 nonce[16];
> > > + __be32 write_counter;
> > > + __be16 addr;
> > > + __be16 block_count;
> > > + __be16 result;
> > > + __be16 req_resp;
> > > +} __packed;
> > > +
> > > +#define RPMB_PROGRAM_KEY 0x1 /* Program RPMB Authentication Key */
> > > +#define RPMB_GET_WRITE_COUNTER 0x2 /* Read RPMB write counter */
> > > +#define RPMB_WRITE_DATA 0x3 /* Write data to RPMB partition */
> > > +#define RPMB_READ_DATA 0x4 /* Read data from RPMB partition */
> > > +#define RPMB_RESULT_READ 0x5 /* Read result request (Internal) */
> > > +
> > > static DEFINE_MUTEX(block_mutex);
> > >
> > > /*
> > > @@ -163,6 +207,7 @@ struct mmc_rpmb_data {
> > > int id;
> > > unsigned int part_index;
> > > struct mmc_blk_data *md;
> > > + struct rpmb_dev *rdev;
> > > struct list_head node;
> > > };
> > >
> > > @@ -2672,7 +2717,6 @@ static int mmc_rpmb_chrdev_open(struct inode *inode, struct file *filp)
> > >
> > > get_device(&rpmb->dev);
> > > filp->private_data = rpmb;
> > > - mmc_blk_get(rpmb->md->disk);
> > >
> > > return nonseekable_open(inode, filp);
> > > }
> > > @@ -2682,7 +2726,6 @@ static int mmc_rpmb_chrdev_release(struct inode *inode, struct file *filp)
> > > struct mmc_rpmb_data *rpmb = container_of(inode->i_cdev,
> > > struct mmc_rpmb_data, chrdev);
> > >
> > > - mmc_blk_put(rpmb->md);
> > > put_device(&rpmb->dev);
> > >
> > > return 0;
> > > @@ -2703,10 +2746,165 @@ static void mmc_blk_rpmb_device_release(struct device *dev)
> > > {
> > > struct mmc_rpmb_data *rpmb = dev_get_drvdata(dev);
> > >
> > > + rpmb_dev_unregister(rpmb->rdev);
> > > + mmc_blk_put(rpmb->md);
> > > ida_simple_remove(&mmc_rpmb_ida, rpmb->id);
> > > kfree(rpmb);
> > > }
> > >
> > > +static void free_idata(struct mmc_blk_ioc_data **idata, unsigned int cmd_count)
> > > +{
> > > + unsigned int n;
> > > +
> > > + for (n = 0; n < cmd_count; n++)
> > > + kfree(idata[n]);
> > > + kfree(idata);
> > > +}
> > > +
> > > +static struct mmc_blk_ioc_data **alloc_idata(struct mmc_rpmb_data *rpmb,
> > > + unsigned int cmd_count)
> > > +{
> > > + struct mmc_blk_ioc_data **idata;
> > > + unsigned int n;
> > > +
> > > + idata = kcalloc(cmd_count, sizeof(*idata), GFP_KERNEL);
> > > + if (!idata)
> > > + return NULL;
> > > + for (n = 0; n < cmd_count; n++) {
> > > + idata[n] = kcalloc(1, sizeof(**idata), GFP_KERNEL);
> > > + if (!idata[n]) {
> > > + free_idata(idata, n);
> > > + return NULL;
> > > + }
> > > + idata[n]->rpmb = rpmb;
> > > + }
> > > +
> > > + return idata;
> > > +}
> > > +
> > > +static void set_idata(struct mmc_blk_ioc_data *idata, u32 opcode,
> > > + int write_flag, u8 *buf, unsigned int buf_bytes)
> > > +{
> > > + /*
> > > + * The size of an RPMB frame must match what's expected by the
> > > + * hardware.
> > > + */
> > > + BUILD_BUG_ON(sizeof(struct rpmb_frame) != 512);
> > > +
> > > + idata->ic.opcode = opcode;
> > > + idata->ic.flags = MMC_RSP_R1 | MMC_CMD_ADTC;
> > > + idata->ic.write_flag = write_flag;
> > > + idata->ic.blksz = sizeof(struct rpmb_frame);
> > > + idata->ic.blocks = buf_bytes / idata->ic.blksz;
> > > + idata->buf = buf;
> >
> > I tested the series on a i.MX8MM with a eMMC connected via the imx-sdhci
> > controller. Reading from RPMB does not work. It ends in timeouts due to
> > no response from the SDHCI controller.
> >
> > If idata->buf is allocated here with kmalloc(buf_bytes, GFP_KERNEL) and
> > the content of buf is copied to the new allocated area, transfers succeed.
> >
> > Is it possible that idata->buf is not DMA capable? Any other ideas?
>
> Thanks for testing. I don't know, the idata->buf is allocated using
> alloc_pages_exact(nr_pages * PAGE_SIZE, GFP_KERNEL | __GFP_ZERO); in
> optee_pool_op_alloc_helper().
Is this really true for idata->buf or isnt the complete RPMB frame memory
allocated like this and therefore idata->buf not page aligned?
For RPMB via tee-supplicant the idata->buf is allocated within memdup_user
and therefore page aligned.
> Alternatively, it's from the memory
> range mapped using memremap() in optee_config_shm_memremap(), but
> that's only if you don't have "dynamic shared memory is enabled" in
> the boot log.
"dynamic shared memory is enabled" is in the bootlog, ..
Thanks for your comments,
Manuel
next prev parent reply other threads:[~2024-04-29 9:41 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-22 9:19 [PATCH v5 0/3] Replay Protected Memory Block (RPMB) subsystem Jens Wiklander
2024-04-22 9:19 ` [PATCH v5 1/3] rpmb: add " Jens Wiklander
2024-04-25 8:37 ` Manuel Traut
2024-04-26 13:08 ` Jens Wiklander
2024-04-22 9:19 ` [PATCH v5 2/3] mmc: block: register RPMB partition with the RPMB subsystem Jens Wiklander
2024-04-25 8:42 ` Manuel Traut
2024-04-26 13:24 ` Jens Wiklander
2024-04-29 9:40 ` Manuel Traut [this message]
2024-04-29 10:08 ` Jens Wiklander
2024-04-29 10:35 ` Manuel Traut
2024-04-29 10:45 ` Jens Wiklander
2024-04-29 11:13 ` Jens Wiklander
2024-04-29 13:13 ` Manuel Traut
2024-05-02 9:53 ` Jens Wiklander
2024-05-03 9:16 ` Manuel Traut
2024-04-29 19:36 ` Avri Altman
2024-05-07 9:21 ` Jens Wiklander
2024-04-22 9:19 ` [PATCH v5 3/3] optee: probe RPMB device using " Jens Wiklander
2024-04-25 9:13 ` Manuel Traut
2024-04-26 13:40 ` Jens Wiklander
2024-05-03 14:37 ` Manuel Traut
2024-05-06 8:34 ` Jens Wiklander
2024-04-23 6:42 ` [PATCH v5 0/3] Replay Protected Memory Block (RPMB) subsystem Avri Altman
2024-04-23 7:29 ` Jens Wiklander
2024-04-23 8:22 ` Avri Altman
2024-04-23 8:44 ` Jens Wiklander
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Zi9rKzz8u8z7cIy0@mecka.net \
--to=manut@mecka.net \
--cc=alexander.usyskin@intel.com \
--cc=ardb@kernel.org \
--cc=arnd@arndb.de \
--cc=bvanassche@acm.org \
--cc=gregkh@linuxfoundation.org \
--cc=ilias.apalodimas@linaro.org \
--cc=jens.wiklander@linaro.org \
--cc=jerome.forissier@linaro.org \
--cc=linus.walleij@linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mmc@vger.kernel.org \
--cc=op-tee@lists.trustedfirmware.org \
--cc=rdunlap@infradead.org \
--cc=shyamsaini@linux.microsoft.com \
--cc=sumit.garg@linaro.org \
--cc=tomas.winkler@intel.com \
--cc=ulf.hansson@linaro.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox