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?)


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.)

  • But I wonder as – tsenapathy Feb 12 '16 at 17:49

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

 readonly      =  1 (on)
$ sudo hdparm -r0 /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
$ sudo umount /dev/mmcblk0p1
$ sudo mount /dev/mmcblk0p1 /mnt
mount: block device /dev/mmcblk0p1 is write-protected, mounting read-only
$ cat /mnt/test
$ touch /mnt/test
touch: cannot touch `/mnt/test': Read-only file system

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.

  • I think you're wrong. Please post a source. – wizlog Nov 6 '11 at 16:18
  • 1
  • @wizlog: Without knowing what you think I'm wrong about, I don't know which claim to post a source for. – David Schwartz Nov 7 '11 at 2:49
  • The reader can ignore the write protect tab – wizlog Nov 7 '11 at 3:44
  • 3
    "Because the notch is detected only by the reader, the protection can be overridden if desired (and if supported by the reader)." - Wikipedia – David Schwartz Nov 7 '11 at 3:52

Its a hardware based switch. Its a feature just blocks any write operations.

If switched, you can't:

  • Move files from or to the SD Card

  • Remove files from the SD Card

  • Copy files to the SD Card

  • Format the SD Card

EDIT Read more here. Note the faint orange circle...

  • 2
    A switch on the left side. Just so the op knows where – Canadian Luke Nov 6 '11 at 15:27
  • 2
    Are you sure the lock actually enforces this though? I've read there are cameras that can (somewhat coincidentally) ignore this and write to the card anyway. – Jane Panda Nov 6 '11 at 15:35
  • 1
    The link you are citing says "Some SD cards also have write-protection built into the card". Some - not all. If you compare the other answers it seems this is an exception. Quite shocking, I think - it seems they did not think about security and viruses at all. 8-{ – Hans-Peter Störr Nov 9 '11 at 19:26
  • 1
    why is this answer down-voted so much? – wizlog Jul 24 '17 at 18:25

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.