On Wed, 6 Apr 2011, MichaÅ MirosÅaw wrote: > 2011/4/6 John Calixto <john.calixto@xxxxxxxxxxxxxx>: > > 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. > > Not all specified ACMDs are mandatory. SD spec 2.00 says that only > 6,13,41,42,51 are mandatory for all cards. This is less than the list > you prepared in the patch. > Hmm... In several places of the full SD spec, and even in the redacted "SD Specifications, Part 1, Physical Layer, Simplified Specification, Version 3.01", it states the security functions are mandatory for all SD cards except ROM cards. For ROM cards, the security ACMDs are expected to be treated as illegal commands, and do not fall back to their CMD equivalents. > It's better not to make those exceptions and instead prepare an > userspace daemon that opens mmcblkX (non-exclusively) and forwards the > requests from unprivileged users to the device (or even implements > application specific API). > OK, this sounds reasonable to me (although I still do not see why non-root, non-privileged users have open() access to /dev/mmcblk0). I will replace the opcode filter with an unconditional check for CAP_SYS_RAWIO. With this capability check, I think I can skip checking for SD vs. MMC. It would be nice for this ioctl to have more general purpose than just enabling secure operations on SD cards (see Arnd Bergmann's intended use as a passthrough for virtual machines). Regarding permissions, the next iteration of this patch will: - Be a single patch containing the main ioctl functionality *and* this capability verification (checking "CAP_SYS_RAWIO", per Alan Cox in this thread). - Only have the check for CAP_SYS_RAWIO. It will *not* have an opcode-specific filter, nor a filter limiting it to just SD cards. Is that satisfactory? John
