Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Enforce MTE protection for writeable file-backed mappings #469

Open
ayrtonm opened this issue Nov 12, 2024 · 4 comments
Open

Enforce MTE protection for writeable file-backed mappings #469

ayrtonm opened this issue Nov 12, 2024 · 4 comments
Assignees

Comments

@ayrtonm
Copy link
Contributor

ayrtonm commented Nov 12, 2024

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 ayrtonm self-assigned this Nov 18, 2024
@ayrtonm
Copy link
Contributor Author

ayrtonm commented Nov 18, 2024

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
Copy link
Contributor

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
Copy link
Contributor Author

ayrtonm commented Nov 22, 2024

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
Copy link
Contributor Author

ayrtonm commented Nov 22, 2024

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants