AARCH64: Fix unmapped memory errors when Top Byte Ignore Addresses is enabled #2165
Conversation
From the perspective of a quick hack on 5.0.1, it is the right place but just you should be careful enough not to shoot your own foot.
Since we will be soon bumping to 5.1.0, I think no extra API is needed? |
| addr = addr & ARM64_TBI_MASK; | ||
| handled = 1; | ||
| } | ||
| #endif |
There was a problem hiding this comment.
I don't think this position is correct for this hack. Also it's inconsistent with the store_helper.
| @@ -2112,6 +2119,9 @@ store_helper(CPUArchState *env, target_ulong addr, uint64_t val, | |||
| struct uc_struct *uc = env->uc; | |||
| HOOK_FOREACH_VAR_DECLARE; | |||
| uintptr_t mmu_idx = get_mmuidx(oi); | |||
| #ifdef TARGET_ARM64 | |||
| addr = addr & ARM64_TBI_MASK; | |||
| #endif | |||
There was a problem hiding this comment.
This position looks way better for the hack.
But I'm unsure if this simple hack is correct and don't have some unwanted effects.
There was a problem hiding this comment.
Of that I am also somewhat unsure; I currently trying to confirm whether the QEMU 5.1.0 solves this problem or if that is not the case. My current understanding is that this still triggers a mapping violation because the address is parsed before the OPCODE is being processed by QEMU, where the still will have a modified address
This MR is far from complete; I honestly need some advice on how to implement this feature properly. I am not familiar enough with QEMU.
Problem
AArch64 uses since ARM v8.0 a feature called "Top Byte Ignore" which ensures that of an 64bit address, the top most byte is not regarded as part of this address, but instead ca be used as complementary memory. This is being used in later ARM processor versions for the Memory Tagging Extensions (MTE) and Pointer Authentication (PAC) hardware mitigations., which are used in recent software to dramtically increase memory safety for legacy C software. In the next Release 2.20 we will have Qemu 5.1.0 which implements MTE.
Why does this cause problems with the current unicorn implementation? The entire hooking and memory mapping systems do not regard this specific ARM/AArch64 feature and evaluate the TBI addresses as-is. These are, however, not mapped, because the are entirely unknown to the mapping,
I stumbled upon this when I struggled with a memory allocator which started using addresses like
0x2000007FFFFFF32aewhich threw an unmapped memory exception. I tried hooking this high address range, but none of the hooks hit. After some ARM research it became apparent that is TBI.Provisionary Solution
This at least works for my current use case: simply using a bit mask on the address to ensure that it is evaluated as if the highest bit does not exist. This does then not intefer with the memory mapping.
Points to discuss
I'am willing to work on this further, but need some direction on:
I will add a simple test once I have figured out working with TBI Pointers in C++.