Message-ID: <CAPDyKFprUeK2UiqAmLvMvZMhtOZa0zmCZ-Gbh_2n1kKF0iOXSA@mail.gmail.com>
Date: Tue, 20 Aug 2024 16:47:15 +0200
From: Ulf Hansson <ulf.hansson@...aro.org>
To: Jens Wiklander <jens.wiklander@...aro.org>
Cc: linux-kernel@...r.kernel.org, linux-mmc@...r.kernel.org, 
	op-tee@...ts.trustedfirmware.org, 
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>, Shyam Saini <shyamsaini@...ux.microsoft.com>, 
	Linus Walleij <linus.walleij@...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>, Manuel Traut <manut@...ka.net>, 
	Mikko Rapeli <mikko.rapeli@...aro.org>, Tomas Winkler <tomas.winkler@...el.com>, 
	Alexander Usyskin <alexander.usyskin@...el.com>
Subject: Re: [PATCH v9 2/4] mmc: block: register RPMB partition with the RPMB subsystem

On Wed, 14 Aug 2024 at 17:36, Jens Wiklander <jens.wiklander@...aro.org> 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@...el.com>
> Signed-off-by: Alexander Usyskin <alexander.usyskin@...el.com>
> Signed-off-by: Jens Wiklander <jens.wiklander@...aro.org>
> Tested-by: Manuel Traut <manut@...ka.net>
> Reviewed-by: Linus Walleij <linus.walleij@...aro.org>

First of all, sorry for the long delay! Besides only one comment, see
more below, this looks good to me.

> ---
>  drivers/mmc/core/block.c | 242 ++++++++++++++++++++++++++++++++++++++-
>  1 file changed, 240 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/mmc/core/block.c b/drivers/mmc/core/block.c
> index 2c9963248fcb..cc7318089cf2 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);
>
>  /*
> @@ -155,6 +199,7 @@ static const struct bus_type mmc_rpmb_bus_type = {
>   * @id: unique device ID number
>   * @part_index: partition index (0 on first)
>   * @md: parent MMC block device
> + * @rdev: registered RPMB device
>   * @node: list item, so we can put this device on a list
>   */
>  struct mmc_rpmb_data {
> @@ -163,6 +208,7 @@ struct mmc_rpmb_data {
>         int id;
>         unsigned int part_index;
>         struct mmc_blk_data *md;
> +       struct rpmb_dev *rdev;
>         struct list_head node;
>  };
>
> @@ -2670,7 +2716,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);

If I understand correctly, the call to mmc_blk_get() is here to
reference count the usage of the md->disk. So when a user decides to
open the chrdev, we are keeping a reference to the corresponding data
around, until the corresponding file descriptor is closed and
mmc_rpmb_chrdev_release() is called. We do the similar thing if the
regular mmc block device is opened.

If we change to increase/decrease the reference count from
mmc_blk_alloc_rpmb_part()/mmc_blk_rpmb_device_release() instead - are
you certain that we are still taking care of the above scenario
correctly?

I guess a test that opens the chrdev and then unbinding the mmc host
driver should tell us. :-)

>
>         return nonseekable_open(inode, filp);
>  }
> @@ -2680,7 +2725,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;
> @@ -2701,10 +2745,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_free(&mmc_rpmb_ida, rpmb->id);
>         kfree(rpmb);
>  }
>

[...]

Kind regards
Uffe

Powered by blists - more mailing lists