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?)
Asked
Active
Viewed 1.8k times
5 Answers
23
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 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.)
RedGrittyBrick
- 85,717
17
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 mishmash 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. https://chdk.fandom.com/wiki/Prepare_your_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
$
Amazon Dies In Darkness
- 9,990
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.
David Schwartz
- 62,365
-1
The lock/switch on an SD card short circuits two pins on the card's connector, which the SD card reader can see. This informs the READER that the SD card should be read-only. However, the microcontroller inside the SD card (which actually does the reading/writing of data to one or multiple flash memory chips, but presents it as single 64Gb or whatever block to the SD card reader) can not detect that this switch has been flipped. Furthermore, a lot of SD card readers - for example ALL microSD card readers - do not have support for the extra connector pin that the lock switch has. So the SD card has the pin, but maybe the reader doesn't.
So as you can see, this isn't a real security model, which is why it was removed for microSD. There is however a command a SD card reader can send to some SD card microcontrollers, that blows a fuse inside, permenently setting the card into read-only mode (enforced by the microcontroller). There is no way to write to it again after the fuse is blown, although a lot of cheaper SD/microSD cards will store the "read-write bit" in the re-writable flash memory and not in one-time-write memory like a fuse, so a command can be sent to the SD card to undo this protection.
There's a lot of caveats to this, as an SD card microcontroller is basically an unknown computer that your PC powers up, so what it does and doesn't do is up to the manufacturer. Many scam/fraud SD cards and USB flash memory have malicious microcontrollers that will present a much larger amount of storage to the OS than what is really installed, because just wraps-around and continues writing over data at the beginning. Of course this totally corrupts the data, but it will pass common memory benchmark testsuites and look good.
So the actual answer to this question is "it depends on the card, and it depends on the reader". I didn't mention that not all SD card readers can actually write the read-write bit to the microcontroller, sometimes the microcontroller needs a password only the manufacturer (and/or industry partners) know, etc.
