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