write-protected usb flash drive
freebsd at qeng-ho.org
Sat May 24 16:54:21 UTC 2014
On 24/05/2014 17:32, Warren Block wrote:
> On Sat, 24 May 2014, Polytropon wrote:
>> On Sat, 24 May 2014 16:22:59 +0100, Arthur Chance wrote:
>>> OK, thought I'd better try my own advice rather than just handing it
>>> out. I put a microSD card out of an old phone into a SanDisk mSD -> SD
>>> adapter and plugged that into my SanDisk SD -> USB adapter, mounted it
>>> (FAT32 file system already on it) and wrote a file to it. Worked as
>>> you'd expect. I then unmounted and unplugged it, flipped the write
>>> protect switch and tried to remount. Result was
>>> mount_msdosfs: /dev/da5s1: Input/output error
>>> Mounting it read-only was fine. So, the write protect is honoured by at
>>> least some SD -> USB adapters.
>> This is already on file system level. It _should_ work the same
>> at upper layers, for example when using dd to write NULs to the
>> device with the write protection on - an error should (correctly)
>> occur in that case.
>> When a r/o mount is forced, the routines accessing that file
>> system cannot avoid the write protection. Still writes are
>> possible _aside of_ the file system which should be prevented
>> by the switch as well. It's probably a good idea to check that
>> too, e. g. put in the card with write protection on and then
>> try dd or newfs on it.
> These are worthwhile tests, but remember that they are done in an
> environment where everything is playing by the rules and trying to do
> the right thing. The drivers will try to support the write-protect switch.
> Malicious software could use custom or patched drivers to ignore the
> settings of the switch or anything else.
> The card reader microcontroller might be responsible for the write
> protect, which would make it much safer than just being honored by
> higher-level drivers.
I'm not sure how one could easily test that.
I will note that when I tried using dd to write to a write protected
card the IO indication light on the USB adapter blinked, which I presume
meant the write attempt wasn't thwarted at the driver level, but I'd
have to plough through at least the umass and cam code to even start to
get some degree of certainty on that.
More information about the freebsd-questions