Hi Loic,
On Wed, Nov 21, 2012 at 3:25 PM, Loic PALLARDY <loic.pallardy@xxxxxx> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
