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

[Loic PALLARDY <loic.pallardy@st.com>]

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.
>
>