Btrfs fails desatrerous on fuzzy tests
Hi!
do you know this paper ?
It was rushing through the Linux press sites in Germany, see also [german]:
http://www.pro-linux.de/news/1/23449/fuzzy-test-f%C3%BCr-dateisysteme-vorgestellt.html
mit freundlichen Grüßen
Jürgen Sauer
Signature · 7 lines
Jürgen Sauer - automatiX GmbH, +49-4209-4699, [email protected] Geschäftsführer: Jürgen Sauer, Gerichtstand: Amtsgericht Walsrode • HRB 120986 Ust-Id: DE191468481 • St.Nr.: 36/211/08000 GPG Public Key zur Signaturprüfung: http://www.automatix.de/juergen_sauer_publickey.gpg
Quoted 4 lines · Juergen Sauer
Hi!
do you know this paper ?
Yes. There were several bugreports resulting from the fuzzing, all fixed in 4.5 and IIRC all of them happen during mount. Thus the awkwardly low amount of time to trigger the bugs. The fuzzing suite is not yet released and instrumenting all the code is not all trivial, but the Oracle guys promised to do a release but at least we have the generated images in the btrfs-progs testsuite.
I'm curious about this level of fuzzing as it can help to make the error handling more robust, but we'll be never able to completely defend against crafted images. For example we can detect a missing extent mapping when looking for it, but we cannot distinguish that from an existing but wrong mapping. That would be like doing a full filesystem integrity check all the time (because we cannot trust any data we read from disk). There are exceptions where there's enough information cached or available from other contexts, but overall too hard to fix. And this applies to all filesystem.s