Fix bug in BSD usermode which leads to memory overwriting

[RoundofThree]

load_elf_sections() mmaps at a fixed address indicated by et_dyn_addr. When emulating big executables, this becomes an issue because it tries to mmap memory regions that overlap with adjacent valid memory mappings due to the size. For example, qemu-morello is mapped at 0x200000; and then the emulated V8 mksnapshot is mapped from 0x0000000000100000 to 0x0000000001848000, overwriting the qemu-morello mapping.

Before load_elf_sections():

gef>  vm
[ Legend:  Code | Heap | Stack ]
Start              End                Offset             Perm Path
0x0000000000200000 0x0000000000513000 0x0000000000000000 r-- /home/zyj20/cheri/output/bsd-user-sdk/bin/qemu-morello
0x0000000000513000 0x00000000009e9000 0x0000000000312000 r-x /home/zyj20/cheri/output/bsd-user-sdk/bin/qemu-morello
[...]

After:

gef>  vm
[ Legend:  Code | Heap | Stack ]
Start              End                Offset             Perm Path
0x0000000000100000 0x0000000001848000 0x0000000000000000 r-- /home/zyj20/v8-work/v8/out/cheri-uncompressed-cross/mksnapshot
0x0000000001848000 0x0000000001849000 0x0000000000000000 r--
[...]

[kwitaszczyk]

Thanks for working on this!

Whilst this resolves the issue of overlaps between ELF sections of the emulated binary and mappings of the user mode binary, it does not resolve the issue of potential conflicts between mmap() calls of an emulated process and mappings of the user mode binary.

I remember that @jrtc27 worked on a change qemu-bsd-user/qemu-bsd-user#51 in upstream (we consider the blitz branch of qemu-bsd-user as upstream for the BSD user mode) to automatically compute guest_base (the -B flag), which shifts the address space of an emulated process, based on the mappings of the user mode. I guess in the long term we would anticipate that change to land in our user mode.

I talked with @RoundofThree that using -B resolves the issue with mksnapshot short term. I think we should discuss with @jrtc27 if Jessica's change is ready to be tested with an experimental run of package building for CheriBSD. If it works without issues, we could land qemu-bsd-user/qemu-bsd-user#51 in our branch even if it is not accepted in upstream.

[kwitaszczyk]

As a temporary workaround, I committed 1cebec9 .