[PATCH v3 0/5] mmc: Add access to RPMB partition

[PATCH v3 0/5] mmc: Add access to RPMB partition

[Loic Pallardy]

The goal of this patchserie is to offer access to MMC RPMB 
(Replay Protected Memory Block) partition.
The RPMB partition is used in general to store some secure data.
It is accessible through a trusted mechanism described in 
JEDEC standard JESD84-A441.

This patchserie proposes following modifications:
- detect RPMB capability and create RPMB block device if supported
- extend MMC sysfs to provide access to RPMB partition size and 
  reliable write sector count (information needed by user space to 
  acces RPMB partition)
- update IOCTL to support RPMB access. This includes automatic partition
  switch and sending of Set Block Count (CMD23) message.

RPMB partition becomes accessible using standard IOCTL interface.
Patches don't include trusted mechanism or any verification. 
It is user space or secure application responsability to provide the right 
command and the entire data frame as defined by JEDEC standard.
---
Changes in v2:
- Correction in patch 2: mmc: card: Do not scan RPMB partitions
  Remove GENHD_FL_EXT_DEVT flag

Changes in v3:
- Add acked-by and reviewed-by tags
---
Loic Pallardy (5):
  mmc: core: Expose access to RPMB partition
  mmc: card: Do not scan RPMB partitions
  mmc: core: Extend sysfs to ext_csd parameters for RPMB support
  mmc: core: Add mmc_set_blockcount feature
  mmc: card: Add RPMB support in IOCTL interface

 Documentation/mmc/mmc-dev-attrs.txt |  7 ++++
 drivers/mmc/card/block.c            | 66 +++++++++++++++++++++++++++++++++++++
 drivers/mmc/core/core.c             | 14 ++++++++
 drivers/mmc/core/mmc.c              | 15 +++++++++
 include/linux/mmc/card.h            |  2 ++
 include/linux/mmc/core.h            |  2 ++
 include/linux/mmc/mmc.h             |  2 ++
 7 files changed, 108 insertions(+)

-- 
1.7.11.1

[PATCH v3 1/5] mmc: core: Expose access to RPMB partition

[Loic Pallardy]

Following JEDEC standard, if the mmc support RPMB partition,
a new interface is created and exposed via /dev/block.
Users will be able to access RPMB partition using standard
mmc IOCTL command.

Signed-off-by: Alex Macro <alex.macro@stericsson.com>
Signed-off-by: Loic Pallardy <loic.pallardy@stericsson.com>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Acked-by: Johan Rudholm <johan.rudholm@stericsson.com>
Reviewed-by: Namjae Jeon <linkinjeon@gmail.com>
---
 drivers/mmc/core/mmc.c   | 11 +++++++++++
 include/linux/mmc/card.h |  2 ++
 include/linux/mmc/mmc.h  |  2 ++
 3 files changed, 15 insertions(+)

diff --git a/drivers/mmc/core/mmc.c b/drivers/mmc/core/mmc.c
index 258b203..8a459cb 100644
--- a/drivers/mmc/core/mmc.c
+++ b/drivers/mmc/core/mmc.c
@@ -480,6 +480,17 @@ static int mmc_read_ext_csd(struct mmc_card *card, u8 *ext_csd)
 
 		card->ext_csd.rel_param = ext_csd[EXT_CSD_WR_REL_PARAM];
 		card->ext_csd.rst_n_function = ext_csd[EXT_CSD_RST_N_FUNCTION];
+
+		/*
+		 * RPMB regions are defined in multiples of 128K.
+		 */
+		card->ext_csd.raw_rpmb_size_mult = ext_csd[EXT_CSD_RPMB_MULT];
+		if (ext_csd[EXT_CSD_RPMB_MULT]) {
+			mmc_part_add(card, ext_csd[EXT_CSD_RPMB_MULT] << 17,
+				EXT_CSD_PART_CONFIG_ACC_RPMB,
+				"rpmb", 0, false,
+				MMC_BLK_DATA_AREA_RPMB);
+		}
 	}
 
 	card->ext_csd.raw_erased_mem_count = ext_csd[EXT_CSD_ERASED_MEM_CONT];
diff --git a/include/linux/mmc/card.h b/include/linux/mmc/card.h
index d76513b..46a5502 100644
--- a/include/linux/mmc/card.h
+++ b/include/linux/mmc/card.h
@@ -81,6 +81,7 @@ struct mmc_ext_csd {
 	unsigned int		boot_ro_lock;		/* ro lock support */
 	bool			boot_ro_lockable;
 	u8			raw_partition_support;	/* 160 */
+	u8			raw_rpmb_size_mult;	/* 168 */
 	u8			raw_erased_mem_count;	/* 181 */
 	u8			raw_ext_csd_structure;	/* 194 */
 	u8			raw_card_type;		/* 196 */
@@ -200,6 +201,7 @@ struct mmc_part {
 #define MMC_BLK_DATA_AREA_MAIN	(1<<0)
 #define MMC_BLK_DATA_AREA_BOOT	(1<<1)
 #define MMC_BLK_DATA_AREA_GP	(1<<2)
+#define MMC_BLK_DATA_AREA_RPMB	(1<<3)
 };
 
 /*
diff --git a/include/linux/mmc/mmc.h b/include/linux/mmc/mmc.h
index d425cab..e73136a 100644
--- a/include/linux/mmc/mmc.h
+++ b/include/linux/mmc/mmc.h
@@ -282,6 +282,7 @@ struct _mmc_csd {
 #define EXT_CSD_RST_N_FUNCTION		162	/* R/W */
 #define EXT_CSD_SANITIZE_START		165     /* W */
 #define EXT_CSD_WR_REL_PARAM		166	/* RO */
+#define EXT_CSD_RPMB_MULT		168	/* RO */
 #define EXT_CSD_BOOT_WP			173	/* R/W */
 #define EXT_CSD_ERASE_GROUP_DEF		175	/* R/W */
 #define EXT_CSD_PART_CONFIG		179	/* R/W */
@@ -333,6 +334,7 @@ struct _mmc_csd {
 
 #define EXT_CSD_PART_CONFIG_ACC_MASK	(0x7)
 #define EXT_CSD_PART_CONFIG_ACC_BOOT0	(0x1)
+#define EXT_CSD_PART_CONFIG_ACC_RPMB	(0x3)
 #define EXT_CSD_PART_CONFIG_ACC_GP0	(0x4)
 
 #define EXT_CSD_PART_SUPPORT_PART_EN	(0x1)
-- 
1.7.11.1

[PATCH v3 2/5] mmc: card: Do not scan RPMB partitions

[Loic Pallardy]

Do not scan rpmb partitions for "soft" partitions, since the rpmb
partition contains protected data. Silences the following
message during boot:

 mmcblkXRPMB: unknown partition table

Signed-off-by: Johan Rudholm <johan.rudholm@stericsson.com>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Reviewed-by: Namjae Jeon <linkinjeon@gmail.com>
---
 drivers/mmc/card/block.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/mmc/card/block.c b/drivers/mmc/card/block.c
index 276d21c..d8edb8d 100644
--- a/drivers/mmc/card/block.c
+++ b/drivers/mmc/card/block.c
@@ -1521,6 +1521,8 @@ static struct mmc_blk_data *mmc_blk_alloc_req(struct mmc_card *card,
 	md->disk->queue = md->queue.queue;
 	md->disk->driverfs_dev = parent;
 	set_disk_ro(md->disk, md->read_only || default_ro);
+	if (area_type & MMC_BLK_DATA_AREA_RPMB)
+		md->disk->flags |= GENHD_FL_NO_PART_SCAN;
 
 	/*
 	 * As discussed on lkml, GENHD_FL_REMOVABLE should:
-- 
1.7.11.1

[PATCH v3 3/5] mmc: core: Extend sysfs to ext_csd parameters for RPMB support

[Loic Pallardy]

Extend current sysfs access to ext_csd rpmb
parameters (RPMB partition size) and rel_sector
information.

Signed-off-by: Loic Pallardy <loic.pallardy@stericsson.com>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Acked-by: Johan Rudholm <johan.rudholm@stericsson.com>
Reviewed-by: Namjae Jeon <linkinjeon@gmail.com>
---
 Documentation/mmc/mmc-dev-attrs.txt | 7 +++++++
 drivers/mmc/core/mmc.c              | 4 ++++
 2 files changed, 11 insertions(+)

diff --git a/Documentation/mmc/mmc-dev-attrs.txt b/Documentation/mmc/mmc-dev-attrs.txt
index 22ae844..0d98fac 100644
--- a/Documentation/mmc/mmc-dev-attrs.txt
+++ b/Documentation/mmc/mmc-dev-attrs.txt
@@ -25,6 +25,8 @@ All attributes are read-only.
 	serial			Product Serial Number (from CID Register)
 	erase_size		Erase group size
 	preferred_erase_size	Preferred erase size
+	raw_rpmb_size_mult	RPMB partition size
+	rel_sectors		Reliable write sector count
 
 Note on Erase Size and Preferred Erase Size:
 
@@ -65,6 +67,11 @@ Note on Erase Size and Preferred Erase Size:
 
 	"preferred_erase_size" is in bytes.
 
+Note on raw_rpmb_size_mult:
+	"raw_rpmb_size_mult" is a mutliple of 128kB block.
+	RPMB size in byte is calculated by using the following equation:
+	RPMB partition size = 128kB x raw_rpmb_size_mult
+
 SD/MMC/SDIO Clock Gating Attribute
 ==================================
 
diff --git a/drivers/mmc/core/mmc.c b/drivers/mmc/core/mmc.c
index 8a459cb..0f2449c 100644
--- a/drivers/mmc/core/mmc.c
+++ b/drivers/mmc/core/mmc.c
@@ -615,6 +615,8 @@ MMC_DEV_ATTR(serial, "0x%08x\n", card->cid.serial);
 MMC_DEV_ATTR(enhanced_area_offset, "%llu\n",
 		card->ext_csd.enhanced_area_offset);
 MMC_DEV_ATTR(enhanced_area_size, "%u\n", card->ext_csd.enhanced_area_size);
+MMC_DEV_ATTR(raw_rpmb_size_mult, "%#x\n", card->ext_csd.raw_rpmb_size_mult);
+MMC_DEV_ATTR(rel_sectors, "%#x\n", card->ext_csd.rel_sectors);
 
 static struct attribute *mmc_std_attrs[] = {
 	&dev_attr_cid.attr,
@@ -630,6 +632,8 @@ static struct attribute *mmc_std_attrs[] = {
 	&dev_attr_serial.attr,
 	&dev_attr_enhanced_area_offset.attr,
 	&dev_attr_enhanced_area_size.attr,
+	&dev_attr_raw_rpmb_size_mult.attr,
+	&dev_attr_rel_sectors.attr,
 	NULL,
 };
 
-- 
1.7.11.1

[PATCH v3 4/5] mmc: core: Add mmc_set_blockcount feature

[Loic Pallardy]

Provide support for automatically sending Set Block Count
(CMD23) messages. Used at least for RPMB support.

Signed-off-by: Alex Macro <alex.macro@stericsson.com>
Signed-off-by: Loic Pallardy <loic.pallardy@stericsson.com>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Acked-by: Johan Rudholm <johan.rudholm@stericsson.com>
Reviewed-by: Namjae Jeon <linkinjeon@gmail.com>
---
 drivers/mmc/core/core.c  | 14 ++++++++++++++
 include/linux/mmc/core.h |  2 ++
 2 files changed, 16 insertions(+)

diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
index 0b6141d..7990e2c 100644
--- a/drivers/mmc/core/core.c
+++ b/drivers/mmc/core/core.c
@@ -1827,6 +1827,20 @@ int mmc_set_blocklen(struct mmc_card *card, unsigned int blocklen)
 }
 EXPORT_SYMBOL(mmc_set_blocklen);
 
+int mmc_set_blockcount(struct mmc_card *card, unsigned int blockcount,
+			bool is_rel_write)
+{
+	struct mmc_command cmd = {0};
+
+	cmd.opcode = MMC_SET_BLOCK_COUNT;
+	cmd.arg = blockcount & 0x0000FFFF;
+	if (is_rel_write)
+		cmd.arg |= 1 << 31;
+	cmd.flags = MMC_RSP_SPI_R1 | MMC_RSP_R1 | MMC_CMD_AC;
+	return mmc_wait_for_cmd(card->host, &cmd, 5);
+}
+EXPORT_SYMBOL(mmc_set_blockcount);
+
 static void mmc_hw_reset_for_init(struct mmc_host *host)
 {
 	if (!(host->caps & MMC_CAP_HW_RESET) || !host->ops->hw_reset)
diff --git a/include/linux/mmc/core.h b/include/linux/mmc/core.h
index 1b431c7..098b7dd 100644
--- a/include/linux/mmc/core.h
+++ b/include/linux/mmc/core.h
@@ -166,6 +166,8 @@ extern int mmc_erase_group_aligned(struct mmc_card *card, unsigned int from,
 extern unsigned int mmc_calc_max_discard(struct mmc_card *card);
 
 extern int mmc_set_blocklen(struct mmc_card *card, unsigned int blocklen);
+extern int mmc_set_blockcount(struct mmc_card *card, unsigned int blockcount,
+			      bool is_rel_write);
 extern int mmc_hw_reset(struct mmc_host *host);
 extern int mmc_hw_reset_check(struct mmc_host *host);
 extern int mmc_can_reset(struct mmc_card *card);
-- 
1.7.11.1

[PATCH v3 5/5] mmc: card: Add RPMB support in IOCTL interface

[Loic Pallardy]

RPMB partition is accessing though /dev/block/mmcXrpmb device
User callers can read and write entire data frame(s) as defined
by JEDEC Standard JESD84-A441, using standard IOCTL interface.

Signed-off-by: Alex Macro <alex.macro@stericsson.com>
Signed-off-by: Loic Pallardy <loic.pallardy@stericsson.com>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Reviewed-by: Namjae Jeon <linkinjeon@gmail.com>
---
 drivers/mmc/card/block.c | 64 ++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 64 insertions(+)

diff --git a/drivers/mmc/card/block.c b/drivers/mmc/card/block.c
index d8edb8d..a9e1f1f 100644
--- a/drivers/mmc/card/block.c
+++ b/drivers/mmc/card/block.c
@@ -126,6 +126,10 @@ enum mmc_blk_status {
 module_param(perdev_minors, int, 0444);
 MODULE_PARM_DESC(perdev_minors, "Minors numbers to allocate per device");
 
+static inline int mmc_blk_part_switch(struct mmc_card *card,
+				      struct mmc_blk_data *md);
+static int get_card_status(struct mmc_card *card, u32 *status, int retries);
+
 static struct mmc_blk_data *mmc_blk_get(struct gendisk *disk)
 {
 	struct mmc_blk_data *md;
@@ -357,6 +361,38 @@ out:
 	return ERR_PTR(err);
 }
 
+static int ioctl_rpmb_card_status_poll(struct mmc_card *card, u32 *status,
+				       u32 retries_max)
+{
+	int err;
+	u32 retry_count = 0;
+
+	if (!status || !retries_max)
+		return -EINVAL;
+
+	do {
+		err = get_card_status(card, status, 5);
+		if (err)
+			break;
+
+		if (!R1_STATUS(*status) &&
+				(R1_CURRENT_STATE(*status) != R1_STATE_PRG))
+			break; /* RPMB programming operation complete */
+
+		/*
+		 * Rechedule to give the MMC device a chance to continue
+		 * processing the previous command without being polled too
+		 * frequently.
+		 */
+		usleep_range(1000, 5000);
+	} while (++retry_count < retries_max);
+
+	if (retry_count == retries_max)
+		err = -EPERM;
+
+	return err;
+}
+
 static int mmc_blk_ioctl_cmd(struct block_device *bdev,
 	struct mmc_ioc_cmd __user *ic_ptr)
 {
@@ -368,6 +404,8 @@ static int mmc_blk_ioctl_cmd(struct block_device *bdev,
 	struct mmc_request mrq = {NULL};
 	struct scatterlist sg;
 	int err;
+	int is_rpmb = false;
+	u32 status = 0;
 
 	/*
 	 * The caller must have CAP_SYS_RAWIO, and must be calling this on the
@@ -387,6 +425,9 @@ static int mmc_blk_ioctl_cmd(struct block_device *bdev,
 		goto cmd_err;
 	}
 
+	if (md->area_type & MMC_BLK_DATA_AREA_RPMB)
+		is_rpmb = true;
+
 	card = md->queue.card;
 	if (IS_ERR(card)) {
 		err = PTR_ERR(card);
@@ -437,12 +478,23 @@ static int mmc_blk_ioctl_cmd(struct block_device *bdev,
 
 	mmc_claim_host(card->host);
 
+	err = mmc_blk_part_switch(card, md);
+	if (err)
+		goto cmd_rel_host;
+
 	if (idata->ic.is_acmd) {
 		err = mmc_app_cmd(card->host, card);
 		if (err)
 			goto cmd_rel_host;
 	}
 
+	if (is_rpmb) {
+		err = mmc_set_blockcount(card, data.blocks,
+			idata->ic.write_flag & (1 << 31));
+		if (err)
+			goto cmd_rel_host;
+	}
+
 	mmc_wait_for_req(card->host, &mrq);
 
 	if (cmd.error) {
@@ -478,6 +530,18 @@ static int mmc_blk_ioctl_cmd(struct block_device *bdev,
 		}
 	}
 
+	if (is_rpmb) {
+		/*
+		 * Ensure RPMB command has completed by polling CMD13
+		 * "Send Status".
+		 */
+		err = ioctl_rpmb_card_status_poll(card, &status, 5);
+		if (err)
+			dev_err(mmc_dev(card->host),
+					"%s: Card Status=0x%08X, error %d\n",
+					__func__, status, err);
+	}
+
 cmd_rel_host:
 	mmc_release_host(card->host);
 
-- 
1.7.11.1

Re: [PATCH v3 5/5] mmc: card: Add RPMB support in IOCTL interface

[shashidhar hiremath]

On Mon, Aug 6, 2012 at 8:42 PM, Loic Pallardy
<loic.pallardy-ext@stericsson.com> wrote:
>
> RPMB partition is accessing though /dev/block/mmcXrpmb device
> User callers can read and write entire data frame(s) as defined
> by JEDEC Standard JESD84-A441, using standard IOCTL interface.
>
> Signed-off-by: Alex Macro <alex.macro@stericsson.com>
> Signed-off-by: Loic Pallardy <loic.pallardy@stericsson.com>
> Acked-by: Linus Walleij <linus.walleij@linaro.org>
> Reviewed-by: Namjae Jeon <linkinjeon@gmail.com>
> ---
>  drivers/mmc/card/block.c | 64 ++++++++++++++++++++++++++++++++++++++++++++++++
>  1 file changed, 64 insertions(+)
>
> diff --git a/drivers/mmc/card/block.c b/drivers/mmc/card/block.c
> index d8edb8d..a9e1f1f 100644
> --- a/drivers/mmc/card/block.c
> +++ b/drivers/mmc/card/block.c
> @@ -126,6 +126,10 @@ enum mmc_blk_status {
>  module_param(perdev_minors, int, 0444);
>  MODULE_PARM_DESC(perdev_minors, "Minors numbers to allocate per device");
>
> +static inline int mmc_blk_part_switch(struct mmc_card *card,
> +                                     struct mmc_blk_data *md);
> +static int get_card_status(struct mmc_card *card, u32 *status, int retries);
> +
>  static struct mmc_blk_data *mmc_blk_get(struct gendisk *disk)
>  {
>         struct mmc_blk_data *md;
> @@ -357,6 +361,38 @@ out:
>         return ERR_PTR(err);
>  }
>
> +static int ioctl_rpmb_card_status_poll(struct mmc_card *card, u32 *status,
> +                                      u32 retries_max)
> +{
> +       int err;
> +       u32 retry_count = 0;
> +
> +       if (!status || !retries_max)
> +               return -EINVAL;
> +
> +       do {
> +               err = get_card_status(card, status, 5);
> +               if (err)
> +                       break;
> +
> +               if (!R1_STATUS(*status) &&
> +                               (R1_CURRENT_STATE(*status) != R1_STATE_PRG))
> +                       break; /* RPMB programming operation complete */
> +
> +               /*
> +                * Rechedule to give the MMC device a chance to continue
> +                * processing the previous command without being polled too
> +                * frequently.
> +                */
> +               usleep_range(1000, 5000);
> +       } while (++retry_count < retries_max);
> +
> +       if (retry_count == retries_max)
> +               err = -EPERM;
> +
> +       return err;
> +}
> +
>  static int mmc_blk_ioctl_cmd(struct block_device *bdev,
>         struct mmc_ioc_cmd __user *ic_ptr)
>  {
> @@ -368,6 +404,8 @@ static int mmc_blk_ioctl_cmd(struct block_device *bdev,
>         struct mmc_request mrq = {NULL};
>         struct scatterlist sg;
>         int err;
> +       int is_rpmb = false;
> +       u32 status = 0;
>
>         /*
>          * The caller must have CAP_SYS_RAWIO, and must be calling this on the
> @@ -387,6 +425,9 @@ static int mmc_blk_ioctl_cmd(struct block_device *bdev,
>                 goto cmd_err;
>         }
>
> +       if (md->area_type & MMC_BLK_DATA_AREA_RPMB)
> +               is_rpmb = true;
> +
>         card = md->queue.card;
>         if (IS_ERR(card)) {
>                 err = PTR_ERR(card);
> @@ -437,12 +478,23 @@ static int mmc_blk_ioctl_cmd(struct block_device *bdev,
>
>         mmc_claim_host(card->host);
>
> +       err = mmc_blk_part_switch(card, md);
> +       if (err)
> +               goto cmd_rel_host;
> +
>         if (idata->ic.is_acmd) {
>                 err = mmc_app_cmd(card->host, card);
>                 if (err)
>                         goto cmd_rel_host;
>         }
>
> +       if (is_rpmb) {
> +               err = mmc_set_blockcount(card, data.blocks,
> +                       idata->ic.write_flag & (1 << 31));
> +               if (err)
> +                       goto cmd_rel_host;
> +       }
> +
>         mmc_wait_for_req(card->host, &mrq);
>
>         if (cmd.error) {
> @@ -478,6 +530,18 @@ static int mmc_blk_ioctl_cmd(struct block_device *bdev,
>                 }
>         }
>
> +       if (is_rpmb) {
> +               /*
> +                * Ensure RPMB command has completed by polling CMD13
> +                * "Send Status".
> +                */
> +               err = ioctl_rpmb_card_status_poll(card, &status, 5);
> +               if (err)
> +                       dev_err(mmc_dev(card->host),
> +                                       "%s: Card Status=0x%08X, error %d\n",
> +                                       __func__, status, err);
> +       }
> +
>  cmd_rel_host:
>         mmc_release_host(card->host);
>
> --
> 1.7.11.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


Hi,
  Any specific reason why the RPMB support is implemented using the
IOCTL interface. Can this be done by the Kernel itself instead of
being initiated by a user space application ?

--
regards,
Shashidhar Hiremath

Re: [PATCH v3 5/5] mmc: card: Add RPMB support in IOCTL interface

[Loic pallardy]

>
>
> Hi,
>   Any specific reason why the RPMB support is implemented using the
> IOCTL interface. Can this be done by the Kernel itself instead of
> being initiated by a user space application ?
>
> --
> regards,
> Shashidhar Hiremath
> --

Hi,
There are several reasons for that:
- RPMB partition supports only few commands, it is not a "standard" partition
- RPMB data access requests a dedicated data frame which contains MAC,
write counter, address...
- Only trusted/secured applications owns authentification key to
calculate MAC (message authentification code) for each data frame.

So implementing RPMB access in kernel will complexify the driver (link
with security, data frame management...) and create vulnerability from
security point of view.
With this solution, kernel driver provides just a pipe between secured
application and eMMC.

Regards,
Loic

Re: Fwd: [PATCH v3 0/5] mmc: Add access to RPMB partition

[Krishna Konda]

On Wed, 2012-11-14 at 12:58 -0800, Krishna Konda wrote:

> From: Loic Pallardy <loic.pallardy-ext@stericsson.com>
> Date: Mon, Aug 6, 2012 at 8:12 AM
> Subject: [PATCH v3 0/5] mmc: Add access to RPMB partition
> To: linux-mmc@vger.kernel.org, Chris Ball <cjb@laptop.org>
> Cc: Linus Walleij <linus.walleij@linaro.org>, STEricsson_nomadik_linux
> <STEricsson_nomadik_linux@list.st.com>, Ulf Hansson
> <ulf.hansson@stericcson.com>, Loic Pallardy
> <loic.pallardy-ext@stericsson.com>
> 
> 
> The goal of this patchserie is to offer access to MMC RPMB
> (Replay Protected Memory Block) partition.
> The RPMB partition is used in general to store some secure data.
> It is accessible through a trusted mechanism described in
> JEDEC standard JESD84-A441.
> 
> This patchserie proposes following modifications:
> - detect RPMB capability and create RPMB block device if supported
> - extend MMC sysfs to provide access to RPMB partition size and
>   reliable write sector count (information needed by user space to
>   acces RPMB partition)
> - update IOCTL to support RPMB access. This includes automatic
> partition
>   switch and sending of Set Block Count (CMD23) message.
> 
> RPMB partition becomes accessible using standard IOCTL interface.
> Patches don't include trusted mechanism or any verification.
> It is user space or secure application responsability to provide the
> right
> command and the entire data frame as defined by JEDEC standard.
> ---
> Changes in v2:
> - Correction in patch 2: mmc: card: Do not scan RPMB partitions
>   Remove GENHD_FL_EXT_DEVT flag
> 
> Changes in v3:
> - Add acked-by and reviewed-by tags
> ---
> Loic Pallardy (5):
>   mmc: core: Expose access to RPMB partition
>   mmc: card: Do not scan RPMB partitions
>   mmc: core: Extend sysfs to ext_csd parameters for RPMB support
>   mmc: core: Add mmc_set_blockcount feature
>   mmc: card: Add RPMB support in IOCTL interface
> 
>  Documentation/mmc/mmc-dev-attrs.txt |  7 ++++
>  drivers/mmc/card/block.c            | 66
> +++++++++++++++++++++++++++++++++++++
>  drivers/mmc/core/core.c             | 14 ++++++++
>  drivers/mmc/core/mmc.c              | 15 +++++++++
>  include/linux/mmc/card.h            |  2 ++
>  include/linux/mmc/core.h            |  2 ++
>  include/linux/mmc/mmc.h             |  2 ++
>  7 files changed, 108 insertions(+)
> 

Hi Loic, Chris, are there any plans to merge these patchsets? I did not
see this in mmc-next.


Thanks,
Krishna Konda
--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, 
hosted by The Linux Foundation

Re: Fwd: [PATCH v3 0/5] mmc: Add access to RPMB partition

[Linus Walleij]

On Wed, Nov 14, 2012 at 10:14 PM, Krishna Konda <kkonda@codeaurora.org> wrote:
> On Wed, 2012-11-14 at 12:58 -0800, Krishna Konda wrote:
>
>> The goal of this patchserie is to offer access to MMC RPMB
>> (Replay Protected Memory Block) partition.
>> The RPMB partition is used in general to store some secure data.
>> It is accessible through a trusted mechanism described in
>> JEDEC standard JESD84-A441.
>
> Hi Loic, Chris, are there any plans to merge these patchsets? I did not
> see this in mmc-next.

I was sort of wondering the same.

Krishna, could you provide your Acked-by/Reviewed-by
tag so as to convince Chris that this is a nice feature?

Yours,
Linus Walleij

Re: Fwd: [PATCH v3 0/5] mmc: Add access to RPMB partition

[Krishna Konda]

On Thu, 2012-11-15 at 09:04 +0100, Linus Walleij wrote:
> > Hi Loic, Chris, are there any plans to merge these patchsets? I did not
> > see this in mmc-next.
> 
> I was sort of wondering the same.
> 
> Krishna, could you provide your Acked-by/Reviewed-by
> tag so as to convince Chris that this is a nice feature?
> 

Sure thing.

-- 

Thanks,
Krishna Konda
-----------------------------------------------------------------------
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, 
hosted by The Linux Foundation
-----------------------------------------------------------------------

Re: Fwd: [PATCH v3 5/5] mmc: card: Add RPMB support in IOCTL interface

[Krishna Konda]

On Fri, 2012-11-16 at 13:17 -0800, Krishna Konda wrote:
> 
> 
> From: Loic Pallardy <loic.pallardy-ext@stericsson.com>
> Date: Mon, Aug 6, 2012 at 8:12 AM
> Subject: [PATCH v3 5/5] mmc: card: Add RPMB support in IOCTL interface
> To: linux-mmc@vger.kernel.org, Chris Ball <cjb@laptop.org>
> Cc: Linus Walleij <linus.walleij@linaro.org>, STEricsson_nomadik_linux
> <STEricsson_nomadik_linux@list.st.com>, Ulf Hansson
> <ulf.hansson@stericcson.com>, Loic Pallardy
> <loic.pallardy-ext@stericsson.com>, Alex Macro
> <alex.macro@stericsson.com>, Loic Pallardy
> <loic.pallardy@stericsson.com>
> 
> 
> RPMB partition is accessing though /dev/block/mmcXrpmb device
> User callers can read and write entire data frame(s) as defined
> by JEDEC Standard JESD84-A441, using standard IOCTL interface.
> 
> Signed-off-by: Alex Macro <alex.macro@stericsson.com>
> Signed-off-by: Loic Pallardy <loic.pallardy@stericsson.com>
> Acked-by: Linus Walleij <linus.walleij@linaro.org>
> Reviewed-by: Namjae Jeon <linkinjeon@gmail.com>

Acked-by: Krishna Konda <kkonda@codeaurora.org>


-- 

Thanks,
Krishna Konda
-----------------------------------------------------------------------
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, 
hosted by The Linux Foundation
-----------------------------------------------------------------------

Re: Fwd: [PATCH v3 4/5] mmc: core: Add mmc_set_blockcount feature

[Krishna Konda]

On Fri, 2012-11-16 at 13:17 -0800, Krishna Konda wrote:
> 
> 
> From: Loic Pallardy <loic.pallardy-ext@stericsson.com>
> Date: Mon, Aug 6, 2012 at 8:12 AM
> Subject: [PATCH v3 4/5] mmc: core: Add mmc_set_blockcount feature
> To: linux-mmc@vger.kernel.org, Chris Ball <cjb@laptop.org>
> Cc: Linus Walleij <linus.walleij@linaro.org>, STEricsson_nomadik_linux
> <STEricsson_nomadik_linux@list.st.com>, Ulf Hansson
> <ulf.hansson@stericcson.com>, Loic Pallardy
> <loic.pallardy-ext@stericsson.com>, Alex Macro
> <alex.macro@stericsson.com>, Loic Pallardy
> <loic.pallardy@stericsson.com>
> 
> 
> Provide support for automatically sending Set Block Count
> (CMD23) messages. Used at least for RPMB support.
> 
> Signed-off-by: Alex Macro <alex.macro@stericsson.com>
> Signed-off-by: Loic Pallardy <loic.pallardy@stericsson.com>
> Acked-by: Linus Walleij <linus.walleij@linaro.org>
> Acked-by: Johan Rudholm <johan.rudholm@stericsson.com>
> Reviewed-by: Namjae Jeon <linkinjeon@gmail.com>

Acked-by: Krishna Konda <kkonda@codeaurora.org>


-- 

Thanks,
Krishna Konda
-----------------------------------------------------------------------
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, 
hosted by The Linux Foundation
-----------------------------------------------------------------------

Re: Fwd: [PATCH v3 3/5] mmc: core: Extend sysfs to ext_csd parameters for RPMB support

[Krishna Konda]

On Fri, 2012-11-16 at 13:17 -0800, Krishna Konda wrote:
> 
> 
> From: Loic Pallardy <loic.pallardy-ext@stericsson.com>
> Date: Mon, Aug 6, 2012 at 8:12 AM
> Subject: [PATCH v3 3/5] mmc: core: Extend sysfs to ext_csd parameters
> for RPMB support
> To: linux-mmc@vger.kernel.org, Chris Ball <cjb@laptop.org>
> Cc: Linus Walleij <linus.walleij@linaro.org>, STEricsson_nomadik_linux
> <STEricsson_nomadik_linux@list.st.com>, Ulf Hansson
> <ulf.hansson@stericcson.com>, Loic Pallardy
> <loic.pallardy-ext@stericsson.com>, Loic Pallardy
> <loic.pallardy@stericsson.com>
> 
> 
> Extend current sysfs access to ext_csd rpmb
> parameters (RPMB partition size) and rel_sector
> information.
> 
> Signed-off-by: Loic Pallardy <loic.pallardy@stericsson.com>
> Acked-by: Linus Walleij <linus.walleij@linaro.org>
> Acked-by: Johan Rudholm <johan.rudholm@stericsson.com>
> Reviewed-by: Namjae Jeon <linkinjeon@gmail.com>

Acked-by: Krishna Konda <kkonda@codeaurora.org>

-- 

Thanks,
Krishna Konda
-----------------------------------------------------------------------
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, 
hosted by The Linux Foundation
-----------------------------------------------------------------------

Re: Fwd: [PATCH v3 2/5] mmc: card: Do not scan RPMB partitions

[Krishna Konda]

On Fri, 2012-11-16 at 13:17 -0800, Krishna Konda wrote:
> 
> 
> From: Loic Pallardy <loic.pallardy-ext@stericsson.com>
> Date: Mon, Aug 6, 2012 at 8:12 AM
> Subject: [PATCH v3 2/5] mmc: card: Do not scan RPMB partitions
> To: linux-mmc@vger.kernel.org, Chris Ball <cjb@laptop.org>
> Cc: Linus Walleij <linus.walleij@linaro.org>, STEricsson_nomadik_linux
> <STEricsson_nomadik_linux@list.st.com>, Ulf Hansson
> <ulf.hansson@stericcson.com>, Loic Pallardy
> <loic.pallardy-ext@stericsson.com>, Johan Rudholm
> <johan.rudholm@stericsson.com>
> 
> 
> Do not scan rpmb partitions for "soft" partitions, since the rpmb
> partition contains protected data. Silences the following
> message during boot:
> 
>  mmcblkXRPMB: unknown partition table
> 
> Signed-off-by: Johan Rudholm <johan.rudholm@stericsson.com>
> Acked-by: Linus Walleij <linus.walleij@linaro.org>
> Reviewed-by: Namjae Jeon <linkinjeon@gmail.com>

Acked-by: Krishna Konda <kkonda@codeaurora.org>

-- 

Thanks,
Krishna Konda
-----------------------------------------------------------------------
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, 
hosted by The Linux Foundation
-----------------------------------------------------------------------

Re: Fwd: [PATCH v3 1/5] mmc: core: Expose access to RPMB partition

[Krishna Konda]

On Fri, 2012-11-16 at 13:16 -0800, Krishna Konda wrote:
> 
> 
> From: Loic Pallardy <loic.pallardy-ext@stericsson.com>
> Date: Mon, Aug 6, 2012 at 8:12 AM
> Subject: [PATCH v3 1/5] mmc: core: Expose access to RPMB partition
> To: linux-mmc@vger.kernel.org, Chris Ball <cjb@laptop.org>
> Cc: Linus Walleij <linus.walleij@linaro.org>, STEricsson_nomadik_linux
> <STEricsson_nomadik_linux@list.st.com>, Ulf Hansson
> <ulf.hansson@stericcson.com>, Loic Pallardy
> <loic.pallardy-ext@stericsson.com>, Alex Macro
> <alex.macro@stericsson.com>, Loic Pallardy
> <loic.pallardy@stericsson.com>
> 
> 
> Following JEDEC standard, if the mmc support RPMB partition,
> a new interface is created and exposed via /dev/block.
> Users will be able to access RPMB partition using standard
> mmc IOCTL command.
> 
> Signed-off-by: Alex Macro <alex.macro@stericsson.com>
> Signed-off-by: Loic Pallardy <loic.pallardy@stericsson.com>
> Acked-by: Linus Walleij <linus.walleij@linaro.org>
> Acked-by: Johan Rudholm <johan.rudholm@stericsson.com>
> Reviewed-by: Namjae Jeon <linkinjeon@gmail.com>

Acked-by: Krishna Konda <kkonda@codeaurora.org>


-- 

Thanks,
Krishna Konda
-----------------------------------------------------------------------
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, 
hosted by The Linux Foundation
-----------------------------------------------------------------------

Re: Fwd: [PATCH v3 0/5] mmc: Add access to RPMB partition

[Linus Walleij]

On Fri, Nov 16, 2012 at 10:11 PM, Krishna Konda <kkonda@codeaurora.org> wrote:
> On Thu, 2012-11-15 at 09:04 +0100, Linus Walleij wrote:
>> > Hi Loic, Chris, are there any plans to merge these patchsets? I did not
>> > see this in mmc-next.
>>
>> I was sort of wondering the same.
>>
>> Krishna, could you provide your Acked-by/Reviewed-by
>> tag so as to convince Chris that this is a nice feature?
>
> Sure thing.

Thanks, Chris you have both ST-Ericsson and CodeAurora ACKs
on this patch set, and no technical remarks seen on v3, can
it be applied?

Yours,
Linus Walleij

Re: [PATCH v3 0/5] mmc: Add access to RPMB partition

[Chris Ball]

Hi Loic,

On Mon, Aug 06 2012, Loic Pallardy wrote:
> The goal of this patchserie is to offer access to MMC RPMB 
> (Replay Protected Memory Block) partition.
> The RPMB partition is used in general to store some secure data.
> It is accessible through a trusted mechanism described in 
> JEDEC standard JESD84-A441.
>
> This patchserie proposes following modifications:
> - detect RPMB capability and create RPMB block device if supported
> - extend MMC sysfs to provide access to RPMB partition size and 
>   reliable write sector count (information needed by user space to 
>   acces RPMB partition)
> - update IOCTL to support RPMB access. This includes automatic partition
>   switch and sending of Set Block Count (CMD23) message.
>
> RPMB partition becomes accessible using standard IOCTL interface.
> Patches don't include trusted mechanism or any verification. 
> It is user space or secure application responsability to provide the right 
> command and the entire data frame as defined by JEDEC standard.

I've merged this to mmc-next for 3.8 now; thanks to everyone who Acked.

If you have any userspace sample code that could be added to mmc-utils
to show how the interface can be used, feel free to send a patch.
Thanks,

- Chris.
-- 
Chris Ball   <cjb@laptop.org>   <http://printf.net/>
One Laptop Per Child

Re: [PATCH v3 0/5] mmc: Add access to RPMB partition

[Linus Walleij]

On Sun, Nov 18, 2012 at 12:12 AM, Chris Ball <cjb@laptop.org> wrote:

> I've merged this to mmc-next for 3.8 now; thanks to everyone who Acked.

Thanks Chris :-)

> If you have any userspace sample code that could be added to mmc-utils
> to show how the interface can be used, feel free to send a patch.

Loïc, Johan: do you have an RPMB example at hand, or could you
cook some nice patch for mmc-utils?

Yours,
Linus Walleij

Re: [PATCH v3 0/5] mmc: Add access to RPMB partition

[Krishna Konda]

On Sat, 2012-11-17 at 18:12 -0500, Chris Ball wrote:
> I've merged this to mmc-next for 3.8 now; thanks to everyone who Acked.
> 
> If you have any userspace sample code that could be added to mmc-utils
> to show how the interface can be used, feel free to send a patch.
> Thanks,
> 
> - Chris.

Thanks Chris. Currently we dont have anything mmc-utils for using this
interface.

-- 

Thanks,
Krishna Konda
-----------------------------------------------------------------------
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, 
hosted by The Linux Foundation
-----------------------------------------------------------------------

Re: [PATCH v3 0/5] mmc: Add access to RPMB partition

[Loic PALLARDY]

On 11/19/2012 07:12 PM, Krishna Konda wrote:
> On Sat, 2012-11-17 at 18:12 -0500, Chris Ball wrote:
>> I've merged this to mmc-next for 3.8 now; thanks to everyone who Acked.
>>
>> If you have any userspace sample code that could be added to mmc-utils
>> to show how the interface can be used, feel free to send a patch.
>> Thanks,
>>
>> - Chris.
>
> Thanks Chris. Currently we dont have anything mmc-utils for using this
> interface.
>
Hi,

I have a test program I'll integrate in mmc-utils.

Regards,
Loic

Re: [PATCH v3 0/5] mmc: Add access to RPMB partition

[Krishna Konda]

On Tue, 2012-11-20 at 09:25 +0100, Loic PALLARDY wrote:
> 
> I have a test program I'll integrate in mmc-utils.
> 
> Regards,
> Loic

Loic/Linus/Chris, I think the IOCTL is not complete in terms of handling
the RPMB requests. Here is why I think that is - let me know your
opinion

There are four request types that are needed to be supported - two under
read category and two under write. They are

Reads
-------
1. Read Write Counter
2. Authenticated data read


Writes
-------
1. Provision RPMB key (though it might be done in a secure environment)
2. Authenticated data read

While its given that the rpmb data frames are going to have that
information encoded in it and the frames will be generated by a secure
piece of code, the request types can be classified as above.

The ioctl interface to do this but currently that does the following
1. Switch partition
2. Set block count
3. One command - whatever is passed in by the userspace application.

So here are the set of commands that need to happen in a rpmb read
operation
1. Switch partition
2. Set block count
3. Write data frame - CMD25 to write the rpmb data frame
4. Set block count
5. Read the data - CMD18 to do the actual read

I am guessing that you would expect the userspace application too call
into the ioctl twice to take care of the 4 & 5 and that might not be an
issue if there was no request processed for mmcqd i.e. no other
process/thread claims the host. But if that were to happen, then the
rpmb operation will fail - please let me know if this assumption or my
understanding of the spec is wrong.

Similarly for rpmb write operation, these are the step involved
1. Switch partition
2. Set block count
3. Write data frame - CMD25 to write the rpmb data frame with data
4. Set block count
5. Read the data - CMD25 to write rpmb data frame indicating that rpmb
result register is about to be read
6. Set block count
7. Read rpmb result - CMD18 to read the rpmb result register

In the case of write, there are an additional two commands compared to
reads. Since all of these needs to be done in one shot, I believe the
current ioctl is not sufficient and this can be handled in the following
ways

1. Extend the current ioctl to handle both cases
2. Add a new ioctl cmd for rpmb requests

Personally I think adding another ioctl is a better way to do this since
the current ioctl will get cumbersome and technically the rpmb requests
are different kind of requests that need to be done atomically. I  am
coding this up as a separate ioctl but before I post the patch, I wanted
feedback on this approach.


-- 

Thanks,
Krishna Konda
-----------------------------------------------------------------------
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, 
hosted by The Linux Foundation
-----------------------------------------------------------------------

Re: [PATCH v3 0/5] mmc: Add access to RPMB partition

[Loic PALLARDY]

Hi Krishna,

On 11/20/2012 07:54 PM, Krishna Konda wrote:
>
> Loic/Linus/Chris, I think the IOCTL is not complete in terms of handling
> the RPMB requests. Here is why I think that is - let me know your
> opinion
>
> There are four request types that are needed to be supported - two under
> read category and two under write. They are
>
> Reads
> -------
> 1. Read Write Counter
> 2. Authenticated data read
>
>
> Writes
> -------
> 1. Provision RPMB key (though it might be done in a secure environment)
> 2. Authenticated data read
Agree
>
> While its given that the rpmb data frames are going to have that
> information encoded in it and the frames will be generated by a secure
> piece of code, the request types can be classified as above.
>
> The ioctl interface to do this but currently that does the following
> 1. Switch partition
> 2. Set block count
> 3. One command - whatever is passed in by the userspace application.
>
> So here are the set of commands that need to happen in a rpmb read
> operation
> 1. Switch partition
> 2. Set block count
> 3. Write data frame - CMD25 to write the rpmb data frame
> 4. Set block count
> 5. Read the data - CMD18 to do the actual read
>
> I am guessing that you would expect the userspace application too call
> into the ioctl twice to take care of the 4&  5
Yes exactly, you have to first send your command and then to read the 
result, 2 IOCTLs are needed

> and that might not be an
> issue if there was no request processed for mmcqd i.e. no other
> process/thread claims the host. But if that were to happen, then the
> rpmb operation will fail - please let me know if this assumption or my
> understanding of the spec is wrong.
I tested this and I don't identify issue.
I have Android running in parallel of my test and lot of other mmc 
accesses are performed in parallel, so my test suite doesn't guarantee 
that the 2 ioctls are contiguous.
I had the same understanding of the RPMB specification, but after tests 
and discussion with our eMMC provider, it appears that RPMB state 
machine is independent of the rest.
>
> Similarly for rpmb write operation, these are the step involved
> 1. Switch partition
> 2. Set block count
> 3. Write data frame - CMD25 to write the rpmb data frame with data
> 4. Set block count
> 5. Read the data - CMD25 to write rpmb data frame indicating that rpmb
> result register is about to be read
> 6. Set block count
> 7. Read rpmb result - CMD18 to read the rpmb result register
>
> In the case of write, there are an additional two commands compared to
> reads. Since all of these needs to be done in one shot, I believe the
> current ioctl is not sufficient and this can be handled in the following
> ways

No needed to do it in one shot. You can send the write and check status 
later.
I tested it, didn't detect any problem.
>
> 1. Extend the current ioctl to handle both cases
> 2. Add a new ioctl cmd for rpmb requests
It was my first implementation, but after internal STE review and eMMC 
check I merge it in existing ioctl.

Please let me know if you detect any issue.

Regards,
Loic
>
> Personally I think adding another ioctl is a better way to do this since
> the current ioctl will get cumbersome and technically the rpmb requests
> are different kind of requests that need to be done atomically. I  am
> coding this up as a separate ioctl but before I post the patch, I wanted
> feedback on this approach.
>
>

Re: [PATCH v3 0/5] mmc: Add access to RPMB partition

[Sundar J. Dev]

Hi Loic,

On Wed, Nov 21, 2012 at 3:25 PM, Loic PALLARDY <loic.pallardy@st.com> wrote:
>
> Hi Krishna,
>
> On 11/20/2012 07:54 PM, Krishna Konda wrote:
> >
> > Loic/Linus/Chris, I think the IOCTL is not complete in terms of handling
> > the RPMB requests. Here is why I think that is - let me know your
> > opinion
> >
> > There are four request types that are needed to be supported - two under
> > read category and two under write. They are
> >
> > Reads
> > -------
> > 1. Read Write Counter
> > 2. Authenticated data read
> >
> >
> > Writes
> > -------
> > 1. Provision RPMB key (though it might be done in a secure environment)
> > 2. Authenticated data read
> Agree
> >
> > While its given that the rpmb data frames are going to have that
> > information encoded in it and the frames will be generated by a secure
> > piece of code, the request types can be classified as above.
> >
> > The ioctl interface to do this but currently that does the following
> > 1. Switch partition
> > 2. Set block count
> > 3. One command - whatever is passed in by the userspace application.
> >
> > So here are the set of commands that need to happen in a rpmb read
> > operation
> > 1. Switch partition
> > 2. Set block count
> > 3. Write data frame - CMD25 to write the rpmb data frame
> > 4. Set block count
> > 5. Read the data - CMD18 to do the actual read
> >
> > I am guessing that you would expect the userspace application too call
> > into the ioctl twice to take care of the 4&  5
> Yes exactly, you have to first send your command and then to read the
> result, 2 IOCTLs are needed
>
> > and that might not be an
> > issue if there was no request processed for mmcqd i.e. no other
> > process/thread claims the host. But if that were to happen, then the
> > rpmb operation will fail - please let me know if this assumption or my
> > understanding of the spec is wrong.
> I tested this and I don't identify issue.
> I have Android running in parallel of my test and lot of other mmc
> accesses are performed in parallel, so my test suite doesn't guarantee
> that the 2 ioctls are contiguous.
> I had the same understanding of the RPMB specification, but after tests
> and discussion with our eMMC provider, it appears that RPMB state
> machine is independent of the rest.
I have seen the issue described by Krishna in one of the Micron eMMC
parts that I tested on. I captured the below CMD snapshot to explain
this better:
    -------> ***** START RPMB TRANSACTION *****
        --> RPMB CMD6 - Switch to RPMB partition
        --> RPMB CMD23 - Set BLK_CNT
        --> RPMB CMD25 - Issue a Mult Blk Write
        -->     RPMB CMD13 - Issue Status CMD and and check for Write completion
    -------> ***** RPMB TRANSACTION ABORTED BY NON-RPMB ACCESS *****
        --> NON-RPMB CMD6 - Switch to Userdata partition
        --> NON-RPMB CMD23 - Set BLK_CNT
        --> NON-RPMB CMD25 - Issue Mutl Blk Write
        --> NON-RPMB CMD12 - Issue Status CMD and and check for completion
    -------> ***** SWITCH BACK TO RPMB PARTITION *****
        --> RPMB CMD6 - Switch back to RPMB partition
        --> RPMB CMD23 - Set BLK_CNT
        --> RPMB CMD18 - Issue a Mult Blk Read
    The RPMB device returns GENERAL FAILURE in the Read data Packet.

Actually, the eMMC JEDEC spec is not very clear on what is the expected
behavior from eMMC chip if a rpmb sequence is interrupted by a non-rpmb
command sequence. It works fine on most Samsung and Toshiba
eMMC parts that I tested rpmb on. But this one Micron eMMC part showed
this problem.
> >
> > Similarly for rpmb write operation, these are the step involved
> > 1. Switch partition
> > 2. Set block count
> > 3. Write data frame - CMD25 to write the rpmb data frame with data
> > 4. Set block count
> > 5. Read the data - CMD25 to write rpmb data frame indicating that rpmb
> > result register is about to be read
> > 6. Set block count
> > 7. Read rpmb result - CMD18 to read the rpmb result register
> >
> > In the case of write, there are an additional two commands compared to
> > reads. Since all of these needs to be done in one shot, I believe the
> > current ioctl is not sufficient and this can be handled in the following
> > ways
>
> No needed to do it in one shot. You can send the write and check status
> later.
> I tested it, didn't detect any problem.
> >
> > 1. Extend the current ioctl to handle both cases
> > 2. Add a new ioctl cmd for rpmb requests
> It was my first implementation, but after internal STE review and eMMC
> check I merge it in existing ioctl.
>
> Please let me know if you detect any issue.
>
> Regards,
> Loic
> >
> > Personally I think adding another ioctl is a better way to do this since
> > the current ioctl will get cumbersome and technically the rpmb requests
> > are different kind of requests that need to be done atomically. I  am
> > coding this up as a separate ioctl but before I post the patch, I wanted
> > feedback on this approach.
> >
> >

Thanks,
--
Sundar Jayakumar Dev

Re: [PATCH v3 0/5] mmc: Add access to RPMB partition

[Loic PALLARDY]

Hi Sundar,

On 11/21/2012 12:02 PM, Sundar J. Dev wrote:
> Hi Loic,
>
> On Wed, Nov 21, 2012 at 3:25 PM, Loic PALLARDY<loic.pallardy@st.com>  wrote:
>>
>>>
>>> I am guessing that you would expect the userspace application too call
>>> into the ioctl twice to take care of the 4&   5
>> Yes exactly, you have to first send your command and then to read the
>> result, 2 IOCTLs are needed
>>
>>> and that might not be an
>>> issue if there was no request processed for mmcqd i.e. no other
>>> process/thread claims the host. But if that were to happen, then the
>>> rpmb operation will fail - please let me know if this assumption or my
>>> understanding of the spec is wrong.
>> I tested this and I don't identify issue.
>> I have Android running in parallel of my test and lot of other mmc
>> accesses are performed in parallel, so my test suite doesn't guarantee
>> that the 2 ioctls are contiguous.
>> I had the same understanding of the RPMB specification, but after tests
>> and discussion with our eMMC provider, it appears that RPMB state
>> machine is independent of the rest.
> I have seen the issue described by Krishna in one of the Micron eMMC
> parts that I tested on. I captured the below CMD snapshot to explain
> this better:
>      ------->  ***** START RPMB TRANSACTION *****
>          -->  RPMB CMD6 - Switch to RPMB partition
>          -->  RPMB CMD23 - Set BLK_CNT
>          -->  RPMB CMD25 - Issue a Mult Blk Write
>          -->      RPMB CMD13 - Issue Status CMD and and check for Write completion
>      ------->  ***** RPMB TRANSACTION ABORTED BY NON-RPMB ACCESS *****
>          -->  NON-RPMB CMD6 - Switch to Userdata partition
>          -->  NON-RPMB CMD23 - Set BLK_CNT
>          -->  NON-RPMB CMD25 - Issue Mutl Blk Write
>          -->  NON-RPMB CMD12 - Issue Status CMD and and check for completion
>      ------->  ***** SWITCH BACK TO RPMB PARTITION *****
>          -->  RPMB CMD6 - Switch back to RPMB partition
>          -->  RPMB CMD23 - Set BLK_CNT
>          -->  RPMB CMD18 - Issue a Mult Blk Read
>      The RPMB device returns GENERAL FAILURE in the Read data Packet.
>
Humm yes log is clear. Micron eMMC doesn't seem to accept interruption 
during RPMB sequence.
Is it working when transfer is not interrupted?
I tested on Toshiba and Sandisk without issue but it is not exhaustive 
enough.
In your test, how many half sectors (256B) are you programming?
I got some general failure when writing more than one half sector on 
some devices, but it has been explained by vendor.

> Actually, the eMMC JEDEC spec is not very clear on what is the expected
> behavior from eMMC chip if a rpmb sequence is interrupted by a non-rpmb
> command sequence. It works fine on most Samsung and Toshiba
> eMMC parts that I tested rpmb on. But this one Micron eMMC part showed
> this problem.
Yes unclear eMMC JEDEC spec about RPMB was reported by our eMMC provider.

>>>
>>> Similarly for rpmb write operation, these are the step involved
>>> 1. Switch partition
>>> 2. Set block count
>>> 3. Write data frame - CMD25 to write the rpmb data frame with data
>>> 4. Set block count
>>> 5. Read the data - CMD25 to write rpmb data frame indicating that rpmb
>>> result register is about to be read
>>> 6. Set block count
>>> 7. Read rpmb result - CMD18 to read the rpmb result register
>>>
>>> In the case of write, there are an additional two commands compared to
>>> reads. Since all of these needs to be done in one shot, I believe the
>>> current ioctl is not sufficient and this can be handled in the following
>>> ways
>>
>> No needed to do it in one shot. You can send the write and check status
>> later.
>> I tested it, didn't detect any problem.
>>>
>>> 1. Extend the current ioctl to handle both cases
>>> 2. Add a new ioctl cmd for rpmb requests
>> It was my first implementation, but after internal STE review and eMMC
>> check I merge it in existing ioctl.
>>
>> Please let me know if you detect any issue.
>>
>> Regards,
>> Loic
>>>
>>> Personally I think adding another ioctl is a better way to do this since
>>> the current ioctl will get cumbersome and technically the rpmb requests
>>> are different kind of requests that need to be done atomically. I  am
>>> coding this up as a separate ioctl but before I post the patch, I wanted
>>> feedback on this approach.
>>>
Solution must be driven by the most constrained device.
In that case, I agree with Krishna, in that case a new ioctl seems to be 
the better approach.

Regards,
Loic
>>>
>
> Thanks,
> --
> Sundar Jayakumar Dev

Re: [PATCH v3 0/5] mmc: Add access to RPMB partition

[Sundar J. Dev]

Hi Loic,

On Wed, Nov 21, 2012 at 11:02 PM, Loic PALLARDY <loic.pallardy@st.com> wrote:
> Hi Sundar,
>
> On 11/21/2012 12:02 PM, Sundar J. Dev wrote:
>> Hi Loic,
>>
>> On Wed, Nov 21, 2012 at 3:25 PM, Loic PALLARDY<loic.pallardy@st.com>  wrote:
>>>
>>>>
>>>> I am guessing that you would expect the userspace application too call
>>>> into the ioctl twice to take care of the 4&   5
>>> Yes exactly, you have to first send your command and then to read the
>>> result, 2 IOCTLs are needed
>>>
>>>> and that might not be an
>>>> issue if there was no request processed for mmcqd i.e. no other
>>>> process/thread claims the host. But if that were to happen, then the
>>>> rpmb operation will fail - please let me know if this assumption or my
>>>> understanding of the spec is wrong.
>>> I tested this and I don't identify issue.
>>> I have Android running in parallel of my test and lot of other mmc
>>> accesses are performed in parallel, so my test suite doesn't guarantee
>>> that the 2 ioctls are contiguous.
>>> I had the same understanding of the RPMB specification, but after tests
>>> and discussion with our eMMC provider, it appears that RPMB state
>>> machine is independent of the rest.
>> I have seen the issue described by Krishna in one of the Micron eMMC
>> parts that I tested on. I captured the below CMD snapshot to explain
>> this better:
>>      ------->  ***** START RPMB TRANSACTION *****
>>          -->  RPMB CMD6 - Switch to RPMB partition
>>          -->  RPMB CMD23 - Set BLK_CNT
>>          -->  RPMB CMD25 - Issue a Mult Blk Write
>>          -->      RPMB CMD13 - Issue Status CMD and and check for Write completion
>>      ------->  ***** RPMB TRANSACTION ABORTED BY NON-RPMB ACCESS *****
>>          -->  NON-RPMB CMD6 - Switch to Userdata partition
>>          -->  NON-RPMB CMD23 - Set BLK_CNT
>>          -->  NON-RPMB CMD25 - Issue Mutl Blk Write
>>          -->  NON-RPMB CMD12 - Issue Status CMD and and check for completion
>>      ------->  ***** SWITCH BACK TO RPMB PARTITION *****
>>          -->  RPMB CMD6 - Switch back to RPMB partition
>>          -->  RPMB CMD23 - Set BLK_CNT
>>          -->  RPMB CMD18 - Issue a Mult Blk Read
>>      The RPMB device returns GENERAL FAILURE in the Read data Packet.
>>
> Humm yes log is clear. Micron eMMC doesn't seem to accept interruption
> during RPMB sequence.
> Is it working when transfer is not interrupted?
Yes, it was working when the rpmb transaction is not interrupted by
non-rpmb access.

> I tested on Toshiba and Sandisk without issue but it is not exhaustive
> enough.
> In your test, how many half sectors (256B) are you programming?
I was programming one half sector.

> I got some general failure when writing more than one half sector on
> some devices, but it has been explained by vendor.
>
>> Actually, the eMMC JEDEC spec is not very clear on what is the expected
>> behavior from eMMC chip if a rpmb sequence is interrupted by a non-rpmb
>> command sequence. It works fine on most Samsung and Toshiba
>> eMMC parts that I tested rpmb on. But this one Micron eMMC part showed
>> this problem.
> Yes unclear eMMC JEDEC spec about RPMB was reported by our eMMC provider.
>
>>>>
>>>> Similarly for rpmb write operation, these are the step involved
>>>> 1. Switch partition
>>>> 2. Set block count
>>>> 3. Write data frame - CMD25 to write the rpmb data frame with data
>>>> 4. Set block count
>>>> 5. Read the data - CMD25 to write rpmb data frame indicating that rpmb
>>>> result register is about to be read
>>>> 6. Set block count
>>>> 7. Read rpmb result - CMD18 to read the rpmb result register
>>>>
>>>> In the case of write, there are an additional two commands compared to
>>>> reads. Since all of these needs to be done in one shot, I believe the
>>>> current ioctl is not sufficient and this can be handled in the following
>>>> ways
>>>
>>> No needed to do it in one shot. You can send the write and check status
>>> later.
>>> I tested it, didn't detect any problem.
>>>>
>>>> 1. Extend the current ioctl to handle both cases
>>>> 2. Add a new ioctl cmd for rpmb requests
>>> It was my first implementation, but after internal STE review and eMMC
>>> check I merge it in existing ioctl.
>>>
>>> Please let me know if you detect any issue.
>>>
>>> Regards,
>>> Loic
>>>>
>>>> Personally I think adding another ioctl is a better way to do this since
>>>> the current ioctl will get cumbersome and technically the rpmb requests
>>>> are different kind of requests that need to be done atomically. I  am
>>>> coding this up as a separate ioctl but before I post the patch, I wanted
>>>> feedback on this approach.
>>>>
> Solution must be driven by the most constrained device.
> In that case, I agree with Krishna, in that case a new ioctl seems to be
> the better approach.

I second that. This must be the right way to do it. I can help test the patch
on this Micron eMMC if needed.

>
> Regards,
> Loic
>>>>
>>
>> Thanks,
>> --
>> Sundar Jayakumar Dev


Thanks,
-- 
Sundar Jayakumar Dev