This has ben focused before, lats time in 2015
(https://patchwork.kernel.org/project/linux-mmc/list/?q=mmc%3A+lock).
Unfortunatly for some reason this never made it into the mainstream kernel.
I was unable to find out the reasons for the rejection, so if I was to
write some patches to the current Kernel, I would like to make sure
beforehand I understand the reasons behind that former rejection.
Furthermore the patches were dependent on the keys subsystem, and I'm
not certain how far that implementation supports using non text keys.
But hey, nothing that couldn't be solved.
According from documentation I could get hands on
(http://users.ece.utexas.edu/~valvano/EE345M/SD_Physical_Layer_Spec.pdf)
it states:
4.3.7.5 Commands Accepted for Locked Card
"The locked card shall accept commands listed below and return response
with setting CARD_IS_LOCKED.
1) Basic class (0)
2) Lock card class (7)
3) CMD16
4) ACMD41
5) ACMD42
All other commands including security commands are treated as illegal
commands."
A.f.a.I.k the card is simply not initilized by the kernel, if it gets
bit 25 of the card status set to 1 (CARD_IS_LOCKED). To overcome this I
would suggest to either create the sysfs and devfs entries, without the
"full availability" of the commands or create the "normal" entries with
limited functionallity. It then would respons with an I/O error on read
write attemp.
Again, as I don't have that much experience with the kernel
architecture, I don't know how an I/O Error could affect other parts of
the Kernel (like Partition table or Filesystem) if a device becomes
present but unresponsive. An alternative therefor would be to create a
stub, that represents the device in all states outside of "normal".
Again, I don't know how well it would be recieved to introduce new
entries in the sysfs like "rmmc0blk0".
Regarding the password required for (un)locking I would suggest to
utilize sysfs to provide the password as a string or hex encoded string
to the kernel.
One last bit, asking "if people actually need this", just don't. If I'm
willing to implement this, there still is Kconfig to decide, if your
kernel gets bloated or not.
--
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
