On Sat, 19 Mar 2011, Arnd Bergmann wrote: > Many of the SD specifications have redacted versions that allow > us to write OS drivers. For instance there is > http://www.sdcard.org/developers//tech/sdcard/pls/simplified_specs/Part_A1_ASSD_Extension_Simplified_Specification_Ver2.00_Final_100518.pdf > that describes some of the "advanced security SD" card Thanks for the reference. I was not aware of those docs. Note that anything related to CPRM is redacted. I suspect it's because it's a separate organization that actually publishes and licenses the CPRM specs - the 4C Entity, LLC. I agree with you that it would be ideal for us if we could include much of the CPRM code directly into the kernel, but I don't see how that's possible at this time. > Ok, so is the protocol designed in a way that you don't need to > mmc_claim_host() across multiple ACMDs to do CPRM? > > > > You may get into a situation where the card is owned by the > > > program that needs to complete talking to it before the kernel > > > can do more block commands, but the program cannot continue until > > > the block driver reads back the program .text section from the > > > card. > > > > > > > Having used mmc_claim_host() (see my previous comment above), the ioctl > > should complete before the kernel gets a chance to page the program out > > shouldn't it? > > Right. But is that enough? The qeustion is whether the card may be > in a state where it's expecting another ACMD after the first ioctl > and cannot deal with regular block commands. > I see your point. The card certainly will not allow access to the secure area if you interleave secure commands with regular, non-secure commands - Failed secure ops would be the immediately observable behaviour that I would expect. However, I am not sure about the potential negative effects on the regular block operations. I will go back and specifically test for these scenarios. Though I must say that in the thousands of hours of manual and automated testing, and at least hundreds of hours of use by end-users, this patch has held its own. Again, I will go back and specifically focus on breaking regular block operations with interleaved injections of ACMDs using this ioctl. > > The patch is only for ACMDs for now. When calling the ioctl with > > cmd=SD_IOC_ACMD, it implies you expect CMD55 to be sent *before* sending > > your command. There are specs that describe the values and behaviours > > of ACMDs. You'll find that the SD card's state machine is pretty > > resilient, and that apps that are messing with tossing garbage ACMDs in > > should expect garbage back out. > > > > I expect for more general purposes, like your qemu passthrough case, you > > would want to add a handler for cmd=SD_IOC_CMD? > > Yes, but I suspect that would mean blocking all other activity on the > same device, possibly with an ioctl for claiming the host for an > extended period of time. > Sure. And if the testing I described above shows that regular block operations are indeed negatively affected, then I'll have to implement that ioctl for claiming the host myself and you'll have a head start! :) John -- 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
