On Thu, 27 Feb, 2020, 10:30 am Theo de Raadt, <[email protected]> wrote:
> > Any of a thousand failures could occur. > > 1 - you didn't fsck those filesystems. > 2 - even if you did, fsck does not create clean filesystems out of garbage. > > The only tooling I know of which could convert a totally broken filesystem > into a less broken filesystem is "dump | restore", but I expect even dump > to be full of bugs. > Thanks for information, @Theo and my apologies for the delayed response. I would say there is no point in doing fsck for my purpose. Because my purpose was filesystem fuzzing. So, I can't use fsck because it will remodify some of the random fuzzed metadata bits and try to make them correct. > > This filesystem was not written to meet the parameters you expect of it. > > We could make 50 changes to try to cope, but it will simply escalate > into directory loops, clusters layed out on top of directory maps which > get modified by fsck, etc etc etc. > > It cannot be won because this filesystem was not written to meet the > parameters you are suddenly expecting of it. > Yeah, you are correct but I have tried the same UFS filesystem fuzzing on NetBSD and it didn't get stuck or I haven't observed any panic/crash. I am not comparing it from NetBSD but I am just thinking whether is it possible to correct them or at least make them less crash/panic. Actually, I have ported the fsfuzzer into OpenBSD with some modification like arc4random() based calls to generate better-randomized input and also improved the logging and stuff for better working. NetBSD also has syzkaller support for filesystem fuzzing. So, I was thinking of something useful on OpenBSD in the same area. I also have some other crashes like page faults, protection faults, etc. Should I raise them on openbsd-bugs? Regards, Neeraj >
