Neither the FFS filesystem code itself, nor the fsck tool, can identify nor repair all loops or block overlaps.
It is not an interchange format. You are treating this like a tar file. It isn't anything like that. Neeraj Pal <[email protected]> wrote: > I read and understood the points like one can find thousand of filesystem > issues like > this, but there is no point of that because the filesystem is not designed to > handle > those issues or those expectations. And, even if we try to solve those issues > then we > will get into loop of other issues. > > Please confirm whether my understanding correct or not? > > On Mon, 16 Mar, 2020, 9:24 am Theo de Raadt, <[email protected]> wrote: > > 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 > > > > > >
