Enforce MTE protection for writeable file-backed mappings without tmpfs

[ayrtonm]

This may not require any changes if running binaries from a tmpfs solves the problem, but we should verify that that's true. See this comment on #314 for details

[ayrtonm]

Labeled as higher-priority since this is likely what's blocking enabling the tls_protected test in #355 and also blocking multiple other tests that apply the CHECK_VIOLATION macro to global data.

[fw-immunant]

Running binaries from tmpfs (I moved the tests/simple1 directory into /tmp (on tmpfs) and symlinked the old location to the new one to account for RPATH) does not seem to affect the MTE violations we observe on writes to statics:

Thread 2.1 received signal SIGSEGV, Segmentation fault
Memory tag violation while accessing address 0x00007ffff7fc0058
Allocation tag 0x1
Logical tag 0x0.
[Switching to Thread 622523.622523]
0x00007ffff7f9fda8 in set_exit_hook ()
(gdb) bt
#0  0x00007ffff7f9fda8 in set_exit_hook ()
#1  0x00007ffff57d0e40 in __wrap_set_exit_hook ()
   from build/tests/simple1/libsimple1_call_gates.so
Backtrace stopped: previous frame inner to this frame (corrupt stack?)
(gdb) disassemble 
Dump of assembler code for function set_exit_hook:
   0x00007ffff7f9fd88 <+0>:	sub	sp, sp, #0x10
   0x00007ffff7f9fd8c <+4>:	mov	x8, x18
   0x00007ffff7f9fd90 <+8>:	and	x9, x8, #0xff00000000000000
   0x00007ffff7f9fd94 <+12>:	add	x8, sp, #0x8
   0x00007ffff7f9fd98 <+16>:	orr	x8, x8, x9
   0x00007ffff7f9fd9c <+20>:	str	x0, [x8]
   0x00007ffff7f9fda0 <+24>:	adrp	x9, 0x7ffff7fc0000 <__do_init.__initialized>
   0x00007ffff7f9fda4 <+28>:	ldr	x8, [sp, #8]
=> 0x00007ffff7f9fda8 <+32>:	str	x8, [x9, #88]
   0x00007ffff7f9fdac <+36>:	add	sp, sp, #0x10
   0x00007ffff7f9fdb0 <+40>:	ret
End of assembler dump.

[ayrtonm]

https://github.com/ARM-software/abi-aa/blob/main/memtagabielf64/memtagabielf64.rst#92global-variable-tagging

Note: this requires special handling for when the linker is invoked implicitly (via the value in PT_INTERP rather than as an argument to the loader binary), as the kernel will load the process into memory, rather than the loader. In these cases, the loader is required to unmap the already-loaded segments, and remap them as anonymous tag-capable mappings, re-loading content from the file where necessary.

Seems like unmapping then remapping segments should work. In our case we should strace QEMU since that may also affect what/whether we need to do this.

[ayrtonm]

Running binaries from tmpfs...

Do you get the same thing when qemu-aarch64 is also in /tmp? Might be easiest to try this with statically-linked qemu

[ayrtonm]

After resolving some stack alignment issues caused by SCTLR_EL1 bits SA and SA0 being set (see PR #495) I managed to run the minimal test on an arch linux chroot on an MTE-enabled pixel. When running the test binary from disk mprotect(PROT_MTE) fails with EINVAL when trying to protect the main binary's read-write segment. Moving the main binary to a tmpfs in the chroot fixes the issue as we expected.

[fw-immunant]

I think it might still be preferable to re-map these pages rather than requiring running from a tmpfs, as doing so either requires finding a mounted tmpfs filesystem or having root privileges to mount one, and then the binary has to be copied there before running. Is it very much harder to re-map pages?