Better support for non-4K pages

[ramosian-glider]

Marc Zyngier notices that syzkaller reproducers always seem to be generated with an implicit requirement that PAGE_SIZE is 4kB. However, arm64 supports 4, 16 and 64kB as the base page size (and e.g. Android is steadily moving towards 16kB).
It means that these reproducers simply don't work (mmap() fails, for example).

Marc asks if it's possible to make the memory-map constants parameterized on PAGE_SIZE.

A somewhat related request is to switch some of the syzkaller instances to non-4K pages.

[ramosian-glider]

For the mappings created by MakePosixMmap() the easiest solution might be to make target.PageSize=64<<10, so that the memory allocations done by the program are always aligned on 64K, even for machines with 4K pages.

But we don't want all programs to unconditionally create 64K-sized mappings for every mmap() call, as this can mask actual bugs on platforms that have PAGE_SIZE=4K.

[ramosian-glider]

There is also a number of descriptions that implicitly assume 4K pages, e.g.:

sys/linux/dev_snd_pcm.txt:mmap$snddsp(addr vma, len len[addr], prot flags[mmap_prot], flags flags[mmap_flags], fd fd_snd_dsp, offset intptr[0:0x10000, 0x1000])
sys/linux/dev_snd_pcm.txt:mmap$snddsp_status(addr vma, len const[0x1000], prot flags[mmap_prot], flags flags[mmap_flags], fd fd_snd_dsp, offset const[SNDRV_PCM_MMAP_OFFSET_STATUS])
sys/linux/dev_snd_pcm.txt:mmap$snddsp_control(addr vma, len const[0x1000], prot flags[mmap_prot], flags flags[mmap_flags], fd fd_snd_dsp, offset const[SNDRV_PCM_MMAP_OFFSET_CONTROL])

[xairy]

Just hit this problem: sys/targets/targets.go defines PageSize to always be 4 << 10 on arm64. This produces the following error on arm64 systems with the 16 KB page size:

proc 0: got output: SYZFAIL: mmap of left data PROT_NONE page failed
want 0x1ffff000, got 0xffffffff (errno 22: Invalid argument)

And syzkaller refuses to work.

[a-nogikh]

Ideally, we should be extracting the page size from the kernel e.g. during the machine check (pkg/vminfo), but I see no straightforward way to propagate that value apart from some big and tricky code refactoring.

It's all as entangled as it can be:

• NumPages depends on PageSize
• syz-sysgen compiles the value from Target into syz-exectutor
  • => we have to refactor syz-executor to accept it dynamically
• program deserialization relies on the page size in multiple places
  • => we have to delay corpus loading until after the machine check
• pkg/vminfo/pkg/rpcserver already need a ready Target object to even start the machine checks.

Furthermore, as targets are becoming more and more specialized (currently there's a hack to have clang/gcc targets + in #6280 we'll be dynamically descriptions + in this case we'd be changing PageSize), it feels like targets.Get() must be completely rewritten to just spawn a new custom target each time based on a list of the dynamically configured properties.

---

There are also (at least) two dirty hacks that might help:

• We could further split the arm64 target into arm64_4k and arm64_16k.
• We could introduce some env variable to control page size at syzkaller run/compilation time (we already use this hack a lot - grep sys/targets for os.Getenv).

[xairy]

An env variable hack seems to make sense: could add a TARGETPAGESIZE parameter to make (similar to make TARGETARCH=arm64 ...) that overrides the default value for the target.