Tracking Issue for AArch64 MTE memory tagging intrinsics

[dheaton-arm]

Feature gate: #![feature(stdarch_aarch64_mte)]

This is a tracking issue for AArch64 MTE memory tagging intrinsics.

Public API

// core::arch::aarch64

pub unsafe fn __arm_mte_create_random_tag<T>(src: *const T, mask: u64) -> *const T;
pub unsafe fn __arm_mte_increment_tag<const OFFSET: i64, T>(src: *const T) -> *const T;
pub unsafe fn __arm_mte_exclude_tag<T>(src: *const T, excluded: u64) -> u64;
pub unsafe fn __arm_mte_set_tag<T>(tag_address: *const T);
pub unsafe fn __arm_mte_get_tag<T>(address: *const T) -> *const T;
pub unsafe fn __arm_mte_ptrdiff<T, U>(a: *const T, b: *const U) -> i64;

Steps / History

• Implementation: Add MTE intrinsics stdarch#1627
• Final comment period (FCP)¹
• Stabilization PR

Unresolved Questions

• None yet.

Footnotes

1. https://std-dev-guide.rust-lang.org/feature-lifecycle/stabilization.html ↩

[RalfJung]

These APIs as-is seem very dangerous to use from Rust, see the discussion here and in rust-lang/miri#3787. The docs for these intrinsics should provide guidance for how to use them correctly in Rust.

[dheaton-arm]

Given that LLVM exposes intrinsics for each of these operations directly, is there as much concern with it tracking these changes incorrectly? I would expect LLVM to expose intrinsics that function correctly within its own model.

Though, certainly, I could see an argument that these should perhaps operate on a TBIBox (or similar) in Rust, differing from the ACLE.

[RalfJung]

I would expect LLVM to expose intrinsics that function correctly within its own model.

That is, unfortunately, not a valid assumption. LLVM is often internally incoherent. For instance, they also expose operations for non-temporal stores but those do not behave properly in the LLVM memory model (Cc llvm/llvm-project#64521). They also expose intrinsics to set the floating-point status register, but it would be UB to actually change that register to anything else (unless special attributes are set on the surrounding code).

LLVM often leaves it to their users to figure out which parts of LLVM can be used together correctly, and which cannot.

[RalfJung]

Cc @rust-lang/opsem

I am in particular concerned about docs like this

/// SAFETY: The pointer provided by this intrinsic will be invalid until the memory
/// has been appropriately tagged with `__arm_mte_set_tag`. If using that intrinsic
/// on the provided pointer is itself invalid, then it will be permanently invalid
/// and Undefined Behavior to dereference it.
pub unsafe fn __arm_mte_create_random_tag<T>(src: *const T, mask: u64) -> *const T;

We have to make sure codegen backends understand what is going on here -- I am not sure where the provenance updates and realloc are happening.

I also don't really understand what __arm_mte_set_tag does -- it says it sets a tag for a 16-byte chunk of memory, but what does that mean? Does it mean that all accesses to this chunk must be done with a pointer that has that tag?

[mrkajetanp]

Does it mean that all accesses to this chunk must be done with a pointer that has that tag?

Yes, that's correct. The idea behind MTE is that we store a 4-bit tag in the top byte of every virtual memory address - that part is handled by the kernel. By default all of the tags are 0000, so all preexisting code already works with MTE.

In this example, __arm_mte_create_random_tag would use the irg instruction and generate a random 4-bit tag for the given pointer.

__arm_mte_set_tag then takes a tagged pointer and uses the stg instruction to actually tag the memory address that the pointer points to with the tag.

Once tagged, if MTE is enabled for the process/thread, every access to that memory address has to be done with a pointer tagged with a matching tag. If the two don't match, the hardware will fault and the process will get a SIGSEGV.

If it can be made to play nice with Rust, MTE could potentially be useful for extra pointer provenance checks. E.g. if we could guarantee that adjacent allocations will always have different memory tags, we could preserve provenance information across pointer-usize-pointer casts and still be able to tell the difference between two pointers with the same address but different provenance. For example:

(imagine we have tagged pointers 'a' and 'b' to adjacent memory locations from different allocations)
let c: usize = (a+1) as usize;
let d: usize = b as usize;
if c == d {
 // unreachable because even if the address of a+1 is the same as b the tags will not match
}
// convert c and d back into pointers - same addresses, different tags
let d_ptr = d as *const i32;
let c_ptr = c as *const i32;
*d; // tag matches - dereference allowed
*c; // tag does not match - hardware fault

[RalfJung]

The general problem is that in Rust (and in C), you can't just offset a pointer by tag << 56 and use it and expect that to make sense -- even if the hardware ignores the top byte, the compiler "sees" that you have offset this pointer way out of bounds and this is UB. I left some links above in my earlier post to the discussion about this.

[mrkajetanp]

Yes certainly, there's more to the story than just the hardware. The point is that if compilers can be convinced to play along, there are a lot of interesting use cases, benefits and implications for e.g. strict provenance that could be gained.
The tricky bit is figuring out how to do that. Arguably I'd say that if a compiler sees tag << 56 as offsetting out of bounds, that is an issue with the compiler. The top byte is not part of the address on any 64 bit architecture I can think of, so changing those bytes is not actually offsetting or moving the pointer. It still points to the same address because those bytes do not determine the address.

For instance, if I print out the address of some Box I have, I get this 0x6000024dc030 - 48 bits. Obviously the remaining bits are still there if I convert it to usize, but they won't be displayed if I print it out because it's not part of the address.

[RalfJung]

It still points to the same address because those bytes do not determine the address.

Hardware doesn't get to just re-define what the "address" is. Rust (and C) have defined the address to be the entire representation of the pointer. I don't see any easy way to change this, the assumption is baked very deep into LLVM. (But maybe it's not so hard to change in LLVM -- I don't know, I am not an expert on LLVM internals. That would be a conversation to be had with the LLVM people. For the purpose of this discussion I will assume LLVM stays unchanged, until someone points at a design that makes LLVM getelementptr and other in-bounds rules work coherently with these intrinsics.)

Arguably I'd say that this is a case of hardware engineers not thinking about the fact that people generally write code in "high-level" languages (like C or Rust), not in assembly...

Hardware can't just unilaterally change the rules and expect that to make sense. There are multiple complicated abstractions interacting here (the ISA and the surface language), and they have to be carefully designed in tandem. Unfortunately one part was now designed and shipped in silicon without considering the other part, so making the entire story work out nicely will be tricky.

For instance, if I print out the address of some Box I have, I get this 0x6000024dc030 - 48 bits. Obviously the remaining bits are still there if I convert it to usize, but they won't be displayed if I print it out because it's not part of the address.

If you print the pointer that is returned from __arm_mte_create_random_tag, it will print all the bits, not just the low 48 bits. (Unless someone changed this recently, but then we should revert that change as it would be wrong. Or at least, it would disconnect the printed value from the actual underlying reality, which involves all the bits. This is not something you can just change by fiat by changing what gets printed, that's not how language design works.)

[mrkajetanp]

Hardware doesn't get to just re-define what the "address" is. Rust (and C) have defined the address to be the entire representation of the pointer

True, but then I'd also say that it's the OS that should be defining what an address is. To take Linux as an example, Linux does not consider the top bits part of the address. The top bits are either 0* for userspace addresses and f* for kernelspace addresses, they're not actually used beyond that. If Rust and C both think that the whole 64 bits are the address, that is not really a correction assumption.

Agreed on the LLVM side, I'm not an LLVM expert either but I will try to consult some about all this.

Or at least, it would disconnect the printed value from the actual underlying reality, which involves all the bits. This is not something you can just change by fiat by changing what gets printed, that's not how language design works.)

Oh yes for sure. This was not a "this proves my point" example, just a somewhat silly illustration, you're obviously right.

The fundamental question here is indeed the one of "what constitutes an address". I agree with the broader approach of programming for the abstract machine rather than a real one, but in designing the abstract machine we also need to consider what it actually runs on. If the abstract machine runs on an OS that doesn't use the top byte which runs on an arch that doesn't use the top byte, then pretending as if the top byte is part of the address for the purposes of the abstract machine seems a little pointless.

Even more so since these mechanisms are already widely used in practice. Every heap allocation on every Android phone that's been updated in the last couple of years already keeps a tag in the top byte:
https://source.android.com/docs/security/test/tagged-pointers

[RalfJung]

I'd say the language gets to define what values in the language mean. 🤷 Anyway it's kind of moot to discuss who is "supposed to" define this, the fact is that LLVM (and likely GCC) have defined this, and there are very good reasons for defining it the way they do that make it hard to change. We can disagree on whether we think this was a mistake or not, but it is the status quo.

Every heap allocation on every Android phone that's been updated in the last couple of years already keeps a tag in the top byte:

If the tag is set by malloc, then everything is fine. As far as Rust is concerned, it is now part of the address and can never change for the lifetime of this allocation.

It is only changing the tag of an already created allocation that causes problems.

[zachs18]

The top byte is not part of the address on any 64 bit architecture I can think of, so changing those bytes is not actually offsetting or moving the pointer. It still points to the same address because those bytes do not determine the address.

(getting a bit off topic here, but) For a concrete example of an architecture where this is not the case: This is not allowed on x86_64, trying to access such a non-canonical address in almost any way causes a fault (which will likely be handled by the OS as a SIGSEGV or similar if not baremetal).

3.3.7.1 Canonical Addressing
In 64-bit mode, an address is considered to be in canonical form if address bits 63 through to the most-significant
implemented bit by the microarchitecture are set to either all ones or all zeros.
Intel 64 architecture defines a 64-bit linear address. Implementations can support less. The first implementation of
IA-32 processors with Intel 64 architecture supports a 48-bit linear address. This means a canonical address must
have bits 63 through 48 set to zeros or ones (depending on whether bit 47 is a zero or one).
Although implementations may not use all 64 bits of the linear address, they should check bits 63 through the
most-significant implemented bit to see if the address is in canonical form. If a linear-memory reference is not in
canonical form, the implementation should generate an exception. In most cases, a general-protection exception
(#GP) is generated. However, in the case of explicit or implied stack references, a stack fault (#SS) is generated.

(from the Intel® 64 and IA-32 Architectures Software Developer’s Manual)

You can tag pointers using these high bits on x86_64 (if you know your target machine has a small enough virtual address space), but the tag must be removed before using the pointer, and tagging as such is still a (wrapping) offset in Rust semantics IIUC.

[mrkajetanp]

For a concrete example of an architecture where this is not the case: This is not allowed on x86_64, trying to access such a non-canonical address in almost any way causes a fault

That is completely beside the point I was making, and while you're right about canonical addressing being a thing that does not make the top byte part of the address on x86_64.
By default aarch64 behaves the same as x86_64, that's why TBI is its own architecture feature that has to be enabled. Non-TBI aarch64 will trap if you try using a tagged pointer too.
The point I was making is that the top byte is not part of the address, which is true for x86_64 just as much.

There are slight differences but x86_64 has its own TBI variants too, and having those enabled makes the cannonicality check you quoted behave differently than it normally does.

• Intel: https://www.phoronix.com/news/Intel-LAM-Merged-Linux-6.4
• AMD: https://www.phoronix.com/news/AMD-Linux-UAI-Zen-4-Tagging

What I'm saying is that from the OS & arch side 64-bit addresses look more like this:

0 0 0 0 0 0 0 0 | 0 0 0 0 0 0 0 0 | 0 0 0 0 0 0 0 0 | 0 0 0 0 0 0 0 0 | 0 0 0 0 1 1 1 1 | 1 1 1 1 1 0 1 0 | 1 0 1 1 1 1 0 1 | 1 1 0 0 1 1 1 1
    63 - 56           55 - 48           47 - 40           39 - 32           31 - 24           23 - 16           15 -  8            7 -  0

|  not address  |  maybe address  |                      actual address                                                                      |

And so pretending from the language side that all 64 bits constitute an address is simply not correct as soon as your code runs on any machine. The top byte would only need to be used for addressing if we wanted to address more than 65536 TiB of memory, which is unlikely to happen anytime soon to say the least.