@zsm-oss @R3x

I have done an initial port of the syz-mount-image for NetBSD. I have used a copy of the sys/linux/filesystems.txt with all the unsupported filesystems removed.

@zsm-oss Could tell me how to test whether the images are getting properly build? Do we have some testing mechanism anywhere?

Could tell me how to test whether the images are getting properly build?

If you mean just based on the descriptions, then I afraid proper images won't be built. The chances that it will build a proper 1MB blob are effectively 0.
We need descriptions of image formats to make it possible for syzkaller to build images. And for that we need some description language extensions that would allow describing metadata layout in an efficient way. But how exactly to do it and if it's possible at all is an open research question.

In a private email you also mentioned:

Huge seed size - We might have issues copying the image to the VM. Also possible issues with mutation of the input.
I feel that we can also maybe port some features from [2] such as the metadata mutator which would help us to mutate the image better.
[2] - https://taesoo.kim/pubs/2019/xu:janus.pdf

If we have good primitives for describing image format, then it would solve the problem of mutation and would make metadata mutator unnecessary.

Consumption of memory in the VM - I saw some memory restrictions being imposed at [3] (Maybe we can do something similar)
[3] - https://github.com/google/syzkaller/blob/master/executor/common_linux.h#L1769

We currently allow at least 200MB of memory per test. Isn't it enough? The largest minimal size of an image that I saw was 128MB (xfs?), so 200MB should be enough, no?

@zsm-oss Could tell me how to test whether the images are getting properly build? Do we have some testing mechanism anywhere?

If you'd like something to poke and prod, the following might help.
syzkaller/tools/syz-imagegen can be used to create a syzkaller program from a binary image. You can move this prog into syzkaller/sys/linux/test.
syzkaller/tools/syz-runtest can be used to run the syzkaller programs inside syzkaller/sys/linux/test. This allows to get a feel for where exactly any failures might occur when trying to mount an image that is valid.
It might be possible to come up with something similar for NetBSD so that you can test the syz_mount_image code and check if a regular working image can be mounted.

@dvyukov @zsm-oss

I had a few queries regarding this. The current implementation seems to be generating segments and writing them into offsets into a file and then mounting that. We have different flags, options for each of the filesystems (I hope I am correct here). Due to this approach, we seem to lack internal parts such as superblocks, inodes etc.

How possible(and logical) do you think it is to generate an entire image for a certain filesystem based on grammar alone. I think potential issues can be bitmaps, flags on structures. Is there a reason that you chose a generic approach than such an approach? Is there a significant advantage for the same over having an image-based mutator (which might be much easier to create)?

I am currently able to mount images on NetBSD - problems I face are

• We need a significantly bigger setup for mounting images (configure the /dev/vndx device and then mount the device)
• We don't have memfd - so I am sticking to writing to a file and then using vndconfig(8) and mount(8) on the command line to get the job of mounting a file done.
• Slightly harder to pass mount arguments. (data argument does not take a comma seperated string of relevant options)

The current implementation seems to be generating segments and writing them into offsets into a file and then mounting that.

Correct.

We have different flags, options for each of the filesystems (I hope I am correct here). Due to this approach, we seem to lack internal parts such as superblocks, inodes etc.

Correct.
We don't have any info about format of the images themselves. We rely on random mutations and seed corpus. Most likely this is not enough to get comprehensive coverage.

How possible(and logical) do you think it is to generate an entire image for a certain filesystem based on grammar alone. I think potential issues can be bitmaps, flags on structures.

This would be the most natural approach for syzkaller, because that's how we generate everything else. The main advantage of that will be that the fuzzer will be able to generate images that are radically different from any real images in a seed corpus, also we won't have any custom procedural code per fs. However, it's unclear if this will work and is feasible. To significant degree it's a research problem and results may even be worth publishing as a paper. As you noted there may be some things that may be hard to describe. Most likely it will require some extensions to the description language. But what are these extensions we don't know yet, we need to try first. We already can do checksums, but we will need a new type of checksum. I would also expect something related to efficient handling of padding (however, maybe existing support for alignment and sizing of structs will work?). We could also employ support for special structures and some limited custom patching/fixing of things, e.g. see what we do for iptables:
https://github.com/google/syzkaller/blob/master/sys/linux/init_iptables.go
Try to take a simplest fs and describe the image format. Then we will know the answer :)

Is there a reason that you chose a generic approach than such an approach?

It was merely something I could in few days and still get some coverage for filesystems.

Is there a significant advantage for the same over having an image-based mutator (which might be much easier to create)?

Custom per-image mutators is also an option. I don't know which is ultimately the best options (and what is even the best is not defined). The main advantage of custom mutators that I see is simplicity: we write custom procedural code and that's easier and we know it works. But the disadvantages are:

• most likely we won't be able to get far from seed corpus
• seeding syzkaller is hard and it can easily lose seed inputs (support for seeding is very ad-hoc)
• we will need procedural code per fs
• we will not be able to reuse this for other complex structures (if we extend descriptions language and figure out how to describe such things, then maybe we can extend this to binder/netfilter/etc)

We need a significantly bigger setup for mounting images (configure the /dev/vndx device and then mount the device)
We don't have memfd - so I am sticking to writing to a file and then using vndconfig(8) and mount(8) on the command line to get the job of mounting a file done.

That's fine to have custom per-OS code here. What exactly is the problem here? :)
I can imagine that this pseudo syscall may timeout, but we can adjust timeouts.

Slightly harder to pass mount arguments. (data argument does not take a comma seperated string of relevant options)

How are they passed? Is it something we can't describe?

syzkaller recently became better at FS fuzzing.

Relevant PRs:

• Image compression and mutation #3455
• Allow syz_mount_image to change directory #3373
• Configurable disabling of syscall generation/mutation/minimisation #3388

We could do better at minimizing the reproducers that mount fs images: https://lore.kernel.org/all/[email protected]/

Note to syzbot maintainers: the C test program contains a compressed ext3
image and decompression code that I think is entirely unnecessary.  All it
does is provide a directory that the afs dynroot can be mounted upon.

This is the only bit of the test that is actually necessary:

  NONFAILING(memcpy((void*)0x2000000001c0, "./file0\000", 8));
  NONFAILING(memcpy((void*)0x2000000002c0, "afs\000", 4));
  NONFAILING(memcpy((void*)0x200000000400, "dyn", 3));
  NONFAILING(*(uint8_t*)0x200000000403 = 0x2c);
  NONFAILING(*(uint8_t*)0x200000000404 = 0);
  syscall(__NR_mount, /*src=*/0ul, /*dst=*/0x2000000001c0ul,
          /*type=*/0x2000000002c0ul, /*flags=*/0ul, /*opts=*/0x200000000400ul);
  NONFAILING(memcpy((void*)0x2000000000c0, "./file0\000", 8));
  syscall(__NR_chdir, /*dir=*/0x2000000000c0ul);
  NONFAILING(memcpy((void*)0x200000000240, "./file1\000", 8));
  syscall(__NR_lstat, /*file=*/0x200000000240ul, /*statbuf=*/0ul);
  NONFAILING(memcpy((void*)0x2000000000c0, ".\000", 2));
  res = syscall(__NR_open, /*file=*/0x2000000000c0ul, /*flags=*/0ul,
                /*mode=*/0ul);
  if (res != -1)
    r[0] = res;
  syscall(__NR_getdents, /*fd=*/r[0], /*ent=*/0x200000001fc0ul,
          /*count=*/0xb8ul);

Basically:

  mount(NULL, "./file0", "afs", 0, "dyn,") = 0
  chdir("./file0")                  = 0
  lstat("./file1", NULL)            = -1 EFAULT (Bad address)
  open(".", O_RDONLY)               = 4
  getdents(4, 0x200000001fc0 /* 5 entries */, 184) = 168

We could set up the same files/folders in the syz-executor environment as we do in the mounted filesystems. E.g. before chrooting into the new location here:

Or could transforming the mount() call to something like mount(NULL, ".", "afs", 0, "dyn,") also work well in this case? Then it could be some extra reproducer minimization step.