4 ms·

Randomly modifying a filesystem image and then fixing up the checksums seems a little unfair. Would it not be reasonable to write code that assumes data that ma

Randomly modifying a filesystem image and then fixing up the checksums seems a little unfair. Would it not be reasonable to write code that assumes data that matches its checksum is valid? Isn't that the point of a checksum?

nabla9 11y ago
> Would it not be reasonable to write code that assumes data that matches its checksum is valid? If you assume that, you don't need checksums in the first place.
- cmurphycode 11y ago
  How's that? If you go read your data, re-checksum it, and that matches the original checksum, then you have confidence (to the strength of your checksum function) that the data is not corrupted.
cmurphycode 11y ago
Having read that slide, I can only guess that they were fixing up checksums for the pages they modified in known valid, but wrong ways. In other words, if there's a page on disk containing a timestamp and the test wants to bump the timestamp downwards to see what happens later on, then you need to fix that page's checksum otherwise the test will not do what you wanted. Of course that means your mutations have to be "fair" in the sense that your new values should still be valid. Because as you stated, just stomping on blocks and fixing up their checksums seems like a silly test.
Deregibus 11y ago
The checksum is only telling you when the value is probably incorrect, it doesn't show that it's correct or meaningful. For example (on a completely hypothetical filesystem/disk), lets say you want to open a file. You read the entry in the filesystem metadata that tells you on what sector that file begins and it gives you a value of 5005. Even if the checksum is correct, the filesystem code still needs to check that a) 5005 is actually within the range of valid sectors, b) that it actually makes sense as a sector value (maybe files must always start on a multiple of 4), c) that the data at that sector actually looks like a file, d) etc. If you don't update the checksum as well when generating the test data then you limit the amount of depth in the testing since most errors would get caught immediately at the checksum validation stage.
the8472 11y ago
Something could generate corrupted data (cosmic rays!), then checksum it and write it to disk.
- cmurphycode 11y ago
  That is very true (and a valid concern) but it's hard to understand what the filesystem should do in this case. Seems to me that the best you can hope for is that the data is corrupted in a way that doesn't make "sense" and the filesystem has a check for that, and quits. Other than duplicating the pages (which is certainly a valid approach) how else can you recover from a data stomp?
samthrowaway123 11y ago
> Would it not be reasonable to write code that assumes data that matches its checksum is valid? Isn't that the point of a checksum? That would be absolutely unreasonable. Filesystems can be malicious, for example Stuxnet transmitted via USB flash drive.

nabla9 11y ago

> Would it not be reasonable to write code that assumes data that matches its checksum is valid? If you assume that, you don't need checksums in the first place.

cmurphycode 11y ago
How's that? If you go read your data, re-checksum it, and that matches the original checksum, then you have confidence (to the strength of your checksum function) that the data is not corrupted.

cmurphycode 11y ago

Having read that slide, I can only guess that they were fixing up checksums for the pages they modified in known valid, but wrong ways. In other words, if there's a page on disk containing a timestamp and the test wants to bump the timestamp downwards to see what happens later on, then you need to fix that page's checksum otherwise the test will not do what you wanted. Of course that means your mutations have to be "fair" in the sense that your new values should still be valid. Because as you stated, just stomping on blocks and fixing up their checksums seems like a silly test.

Deregibus 11y ago

The checksum is only telling you when the value is probably incorrect, it doesn't show that it's correct or meaningful. For example (on a completely hypothetical filesystem/disk), lets say you want to open a file. You read the entry in the filesystem metadata that tells you on what sector that file begins and it gives you a value of 5005. Even if the checksum is correct, the filesystem code still needs to check that a) 5005 is actually within the range of valid sectors, b) that it actually makes sense as a sector value (maybe files must always start on a multiple of 4), c) that the data at that sector actually looks like a file, d) etc. If you don't update the checksum as well when generating the test data then you limit the amount of depth in the testing since most errors would get caught immediately at the checksum validation stage.

the8472 11y ago

Something could generate corrupted data (cosmic rays!), then checksum it and write it to disk.

cmurphycode 11y ago
That is very true (and a valid concern) but it's hard to understand what the filesystem should do in this case. Seems to me that the best you can hope for is that the data is corrupted in a way that doesn't make "sense" and the filesystem has a check for that, and quits. Other than duplicating the pages (which is certainly a valid approach) how else can you recover from a data stomp?

samthrowaway123 11y ago

> Would it not be reasonable to write code that assumes data that matches its checksum is valid? Isn't that the point of a checksum? That would be absolutely unreasonable. Filesystems can be malicious, for example Stuxnet transmitted via USB flash drive.