munmap() rounding up page logic potentially causes memory faults

[rishabhBudhouliya]

Bug

lind-wasm/src/rawposix/src/fs_calls.rs

Lines 1103 to 1106 in c715056

	let rounded_addr = round_up_page(addr as u64) as usize;
	if rounded_addr != addr as usize {
	return syscall_error(Errno::EINVAL, "munmap", "address it not aligned");
	}

While bootstrapping Postgres, postgres calls:

munmap(addr=0x7b22848e6000, len=0x1a34

This len: 0x1a34 translates to 6,708 bytes. Our munmap syscall implementation rounds this up to 2 pages and then we call:

 mmap(0x7b22848e6000, 0x2000, PROT_NONE, MAP_FIXED | MAP_ANONYMOUS | MAP_PRIVATE, -1, 0)

This means there is overlapping memory that might be already assigned that is completely overridden by this calls behavior (MAP_FIXED).

So effectively, lind wipes:

  Page 1:  0x7b22848e6000 → 0x7b22848e7000   (what postgres asked to unmap)                                                                           
  Page 2:  0x7b22848e7000 → 0x7b22848e8000   (the SHMAT PAGE)

This may be the reason why we see the panic:

thread 'lind-fork-2' (292848) panicked at /home/lind/lind-wasm/src/wasmtime/crates/lind-multi-process/src/lib.rs:1190:50:

exec-ed module error: failed to run main module
Caused by:
    0: failed to invoke command default
    1: memory fault at wasm address 0xffae7010 in linear memory of size 0x100000000
    2: wasm trap: out of bounds memory access
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

Evidence

I changed the round_up to round_down(0x1a34) = 0x1000 (1 page, 4,096 bytes) and didn't see the memory fault and was consequently able to make postgres run