Is the lock mechanism on an SD card hardware, firmware, or software (driver,OS) enforced?

Where is the lock to read-only mode enforced with SD cards? Is this done inside the card itself physically, in the firmware of readers, or in the OS? (Some other place?)

Solution 1:

If you read the SD Specifications Part 1 Physical Layer Simplified Specification, section 4.3.6 "Write Protect Management" says

Three write protect methods are supported in the SD Memory Card as follows:
- Mechanical write protect switch (Host responsibility only)
- Card internal write protect (Card's responsibility)
- Password protection card lock operation.

Mechanical Write Protect Switch

A mechanical sliding tablet on the side of the card (refer to the Part 1 Mechanical Addenda) will be used by the user to indicate that a given card is write protected or not. If the sliding tablet is positioned in such a way that the window is open it means that the card is write protected. If the window is close the card is not write-protected. A proper, matched, switch on the socket side will indicate to the host that the card is write-protected or not. It is the responsibility of the host to protect the card. The position of the write protect switch is unknown to the internal circuitry of the card.

(my emphasis)

A TOSHIBA SD Card Specification says

CMD28 SET_WRITE_PROT - Internal Write Protection is not implemented.
CMD29 CLR_WRITE_PROT - Internal Write Protection is not implemented.
CMD30 SEND_WRITE_PROT - Internal Write Protection is not implemented.

…

2)Non Supported Functions:
Card ‘s Internal Write Protect (Optional in PHYSICAL LAYER SPECIFICATION 4.3.5.)

Solution 2:

At my work, we use SD cards in an embedded system. If we try to boot up with a card that is locked, we'll get a kernel panic. This wasn't a big deal until we got a batch of SD cards that had very loose write switches: the act of inserting the card into the reader was sometimes enough to move the switch and lock the card. A lot of people started trying to come up with mechanical options to prevent this, like sticking a piece of tape on each SD card, but in the end we fixed this by changing one line of source code in the Linux kernel. Now when an SD card is detected with the switch set to read-only, we simply ignore the switch and happily write data to the card whenever we want to.

This is from our crazy mismash of backports so I doubt this patch would apply cleanly anywhere, but if you want to experiment with your own kernel, this is a good starting point:

--- include/linux/mmc/card.h    (revision 1423)
+++ include/linux/mmc/card.h    (revision 1424)
@@ -125,7 +125,7 @@
 #define mmc_card_blockaddr(c)  ((c)->state & MMC_STATE_BLOCKADDR)

 #define mmc_card_set_present(c)    ((c)->state |= MMC_STATE_PRESENT)
-#define mmc_card_set_readonly(c) ((c)->state |= MMC_STATE_READONLY)
+#define mmc_card_set_readonly(c) {printk("Ignoring MMC read-only switch\n");}
 #define mmc_card_set_highspeed(c) ((c)->state |= MMC_STATE_HIGHSPEED)
 #define mmc_card_set_blockaddr(c) ((c)->state |= MMC_STATE_BLOCKADDR)

If you don't feel like patching and building a Linux kernel but you do have a Canon P&S camera, you can use CHDK to write files (pictures) to a write-protected SD card (when the camera turns on, the OF checks the state of the switch; when set to RO it will auto-load firmware from the SD card. This allows users to boot directly into CHDK; then CHDK ignores the state of the switch so it can still write pictures to the card; see e.g. http://chdk.wikia.com/wiki/Bootable_SD_card).

You can also write to a write-protected SD card in Linux by turning off the readonly flag with hdparm and remounting the card:

$ mount | grep mmc
/dev/mmcblk0p1 on /media/hello type ext3 (ro,nosuid,nodev,relatime,errors=continue,user_xattr,acl,barrier=1,data=ordered,uhelper=udisks)
$ touch /media/hello/test
touch: cannot touch `/media/hello/test': Read-only file system
$ sudo hdparm -r /dev/mmcblk0p1

/dev/mmcblk0p1:
 readonly      =  1 (on)
$ sudo hdparm -r0 /dev/mmcblk0p1

/dev/mmcblk0p1:
 setting readonly to 0 (off)
 readonly      =  0 (off)
$ touch /media/hello/test
touch: cannot touch `/media/hello/test': Read-only file system
$ sudo mount -t ext3 -o rw,remount /dev/mmcblk0p1 /media/hello
$ touch /media/hello/test
$ echo goodbye > /media/hello/test
$ cat /media/hello/test
goodbye
$ sudo umount /dev/mmcblk0p1
$ sudo mount /dev/mmcblk0p1 /mnt
mount: block device /dev/mmcblk0p1 is write-protected, mounting read-only
$ cat /mnt/test
goodbye
$ touch /mnt/test
touch: cannot touch `/mnt/test': Read-only file system
$ 

Solution 3:

It depends on the reader. The reader can ignore the write protect tab. The reader can have firmware that disables writing if the write protect tab is engaged. The reader can have a software driver that disables writing if the write protect tab is engaged. In practice, the vast majority of readers do it in firmware.