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@linaro.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@intel.com Signed-off-by: Alexander Usyskin alexander.usyskin@intel.com Signed-off-by: Jens Wiklander jens.wiklander@linaro.org Tested-by: Manuel Traut manut@mecka.net Reviewed-by: Linus Walleij linus.walleij@linaro.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