3 ms·
For a new device (ie no existing files on it), wouldn't the simplest approach be to full block 1 (whether 512 or 4k bytes) with a series of "1"'s, block 2 with
by justinclift 2y ago
For a new device (ie no existing files on it), wouldn't the simplest approach be to full block 1 (whether 512 or 4k bytes) with a series of "1"'s, block 2 with a series of "2"'s, (etc). ie incrementing the number that gets written as the block number being written to is written.
Reading that back (either the full device or a random sample) should pretty quickly identify whether things are still in their expected location.
- mark254 2y agoWell, with the remaining trust available at this point you might just as well use something cryptographically secure, like encrypted ones, twos, or simple HMACs of the block number. A too-simple scheme is likely to be detected (and bypassed!) by the firmware a nearly no time.
- justinclift 2y agoSure, that's a decent idea too. :)
- deleted 2y ago[deleted]
- jasomill 2y agoSimpler: fill the drive with random data, hashing as you go, flush the kernel's buffer cache, hash the entire contents of the drive, and compare. Conceptually, # tee /dev/DEVICE </dev/random | sha256sum # echo 1 > /proc/sys/vm/drop_caches # sha256sum /dev/DEVICE though I wouldn't expect this exact command sequence to work unless tee's buffer size divides /dev/DEVICE's capacity and tee errors out writing past the end of /dev/DEVICE before writing to stdout.
- blibble 2y agoI did exactly this earlier last week the drive size divided by 4MB, so dd with bs=4M and fixed count (with oflag=direct you don't even need to drop caches)
- justinclift 2y agoOh, that's a clever way of doing things. The "write the block #'s to the given block" would help identify where a fraudulent device goes wrong. But for just checking if a device is storing data 100% correctly then your way would probably be more robust. :)