It is like you didn't read and understand the points I was making. Neeraj Pal <[email protected]> wrote:
> 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 > > >
