On Wed, May 9, 2018 at 4:48 AM, Eric Sandeen <sandeen@xxxxxxxxxxx> wrote: > > > On 5/8/18 2:52 AM, Dmitry Vyukov wrote: >>> Or put another way, how did you arrive at the fs image values in the reproducer, >>> i.e.: >> Currently they are completely random, nobody taught syzkaller about AGFs, etc. > > So you just combine a few megabytes of purely random bits out of thin air until > you get something that approximates an xfs filesystem? Google must have more > computing power than I was aware of. syzbot uses very few cores for fuzzing of all of the hundreds of kernel subsystems. But syzkaller (the underlying fuzzer) uses coverage-guidance and this makes fuzzing exponentially more efficient than blind techniques. Coverage-guidance is also combined with grammar-based generation techniques, which gives additional synergy (though there are no grammar descriptions for filesystem formats at the moment). Does "xfstests fuzzing infrastructure" use coverage-guidance? If not, it would be useful to add. Among some solutions there are LibFuzzer (https://llvm.org/docs/LibFuzzer.html), AFL (http://lcamtuf.coredump.cx/afl/), kernel-fuzzing (https://github.com/oracle/kernel-fuzzing). I don't know how xfstests fuzzing works, so I can't say what would be more suitable there. >>> oid loop() >>> { >>> memcpy((void*)0x20000000, "xfs", 4); >>> memcpy((void*)0x20000100, "./file0", 8); >>> *(uint64_t*)0x20000200 = 0x20010000; >>> memcpy((void*)0x20010000, >>> "\x58\x46\x53\x42\x00\x00\x10\x00\x00\x00\x00\x00\x00\x00\x10\x00\x00" >>> "\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x9f\x98" >>> "\x99\xff\xcb\xa1\x4e\xe6\xad\x52\x08\x20\x67\x09\xed\x75\x00\x00\x00" >>> "\x00\x00\x00\x00\x04\x00\x00\x00\x00\x00\x00\x35\xe0\x00\x00\x00\x00" >>> "\x00\x00\x35\xe1\x00\x00\x00\x00\x00\x00\x35\xe2\x00\x00\x00\x01\x00" >>> "\x00\x10\x00\x00\x00\x00\x01\x00\x00\x00\x00\x00\x00\x03\x55\xb4\xa4" >>> "\x02\x00\x01\x00\x00\x10\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00" >>> "\x00\x0c\x09\x08\x04\x0c\x00\x00\x19\x00\x00\x00\x00\x00\x00\x00\x40" >>> "\x00\x00\x00\x00\x00\x00\x00\x3d\x00\x00\x00\x00\x00\x00\x0c\xa3\x00" >>> "\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00" >>> "\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02\x00\x00\x00" >>> "\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x01\x00\x00\x02\x02", >>> 204); >>> >>> ... >>> >>> The in-memory xfs filesystem it constructs is damaged, is that an intentional >>> part of the fuzzing during the test? >> Yes, invalid inputs is part of testing. > -- To unsubscribe from this list: send the line "unsubscribe linux-xfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
