Re: [PATCH v3 0/5] mmc: Add access to RPMB partition
Hi Loic, On Wed, Nov 21, 2012 at 11:02 PM, Loic PALLARDY loic.palla...@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 PALLARDYloic.palla...@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 -- To unsubscribe from this list: send the line unsubscribe linux-mmc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 0/5] mmc: Add access to RPMB partition
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
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 PALLARDYloic.palla...@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
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
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 --- -- To unsubscribe from this list: send the line unsubscribe linux-mmc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 0/5] mmc: Add access to RPMB partition
On Sun, Nov 18, 2012 at 12:12 AM, Chris Ball c...@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 -- To unsubscribe from this list: send the line unsubscribe linux-mmc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 0/5] mmc: Add access to RPMB partition
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 --- -- To unsubscribe from this list: send the line unsubscribe linux-mmc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Fwd: [PATCH v3 0/5] mmc: Add access to RPMB partition
On Fri, Nov 16, 2012 at 10:11 PM, Krishna Konda kko...@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 -- To unsubscribe from this list: send the line unsubscribe linux-mmc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Fwd: [PATCH v3 0/5] mmc: Add access to RPMB partition
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 --- -- To unsubscribe from this list: send the line unsubscribe linux-mmc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Fwd: [PATCH v3 0/5] mmc: Add access to RPMB partition
On Wed, Nov 14, 2012 at 10:14 PM, Krishna Konda kko...@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 -- To unsubscribe from this list: send the line unsubscribe linux-mmc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Fwd: [PATCH v3 0/5] mmc: Add access to RPMB partition
On Wed, 2012-11-14 at 12:58 -0800, Krishna Konda wrote: From: Loic Pallardy loic.pallardy-...@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 c...@laptop.org Cc: Linus Walleij linus.wall...@linaro.org, STEricsson_nomadik_linux stericsson_nomadik_li...@list.st.com, Ulf Hansson ulf.hans...@stericcson.com, Loic Pallardy loic.pallardy-...@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 -- To unsubscribe from this list: send the line unsubscribe linux-mmc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 0/5] mmc: Add access to RPMB partition
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 -- To unsubscribe from this list: send the line unsubscribe linux-mmc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
