On Tue, 5 Apr 2011, Andrei Warkentin wrote: > Could you check the SD behavior for undefined ACMDs? If I do ACMD25, > and ACMD25 is not defined, will it be executed as CMD25? This is the > MMC behavior as I have mentioned. The SD spec has a similar paragraph about unspecified ACMD opcodes - they should be treated as the equivalent CMD opcodes. However, all of the opcodes that I listed are indeed specified. So, if the card identifies itself as an SD card, it must implement those opcodes. If it identifies itself as an SD card, and it does *not* implement the ACMD opcodes I listed, then it likely "fell out the back door of the manufacturing facility and landed on a store shelf" ;) ... its quality/correct performance/reliability is unlikely. > If so, that means you will be able to bypass access control and be > able to (at the very least) read/write block as non-root. > In my opinion, this is where we should defer to the UNIX file permissions on the device node. I know that my normal user account does not have permission to open() the device node directly (do distros really do that???). I think that if you are allowing a non-root user to open() the device node for your mmcblk device, you take on the all the risk that entails. > Is there a way for SD to verify which ACMDs the card actually > supports? As far as MMC is concerned - no. I really wish ACMD had > their own classes as well. > Unfortunately not. Would it help to also check (mode & FMODE_WRITE) before allowing these operations? At least then, the actions are limited to what you could already do with plain old read(). 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
