Memory Tag Extension (MTE) in Armv8.5-A

Make it to the Right and Larger Audience


Memory Tag Extension (MTE) in Armv8.5-A

ARM blog  Arm A-Profile Architecture Developments 2018: Armv8.5-A announces several key features in Armv 8.5-A including memory tagging extension.


Armv8.5-A incorporates a new feature called Memory Tagging. When Memory Tagging is in use, a tag is assigned to each memory allocation. All accesses to memory must be made via a pointer with the correct tag. Use of an incorrect tag is noted and the operating system can choose to report it to the user immediately, or to note the process in which it occurred, for later investigation.

Memory Tagging can be used in a number of scenarios. During development, it can be used to detect memory errors in the test environment. Following deployment of an application, it can be used to detect issues in the field, and to provide feedback to the developer. Once feedback has been received, vulnerabilities can be analyzed and addressed before they are exploited by an attacker.


What is memory tagging and which issue(s) does it tend to resolve? Here is a Youtube video presented by Kostya Serebryany from Google.


Below is just a recapture of this video for a quick reference. Check above video for details.


Memory access issues such as out of range access and access to freed memory are common software bugs which also raise security concern that hackers can exploit these loopholes to tap into system.

There is an existing solution called Address Sanitizer (ASAN) to resolve these issues. During compiling, one byte metadata is allocated to every 8 bytes real data. Metadata shows real data is valid or not. Software accesses both real data and metadata. If metadata shows data is not valid, real data should be discarded.

But if a data element is surrounded by other valid data, out of range access can not be detected by metadata since metadata shows out-of-range data are also valid. To resolve it, ASAN needs to put a “redzone” around valid data. out-of-range access may hit redzone and therefore detect issue. But obviously it is also possible out-of-range access can hit some valid data far away and issue can not be detected.

If a data is freed, system should try to mark freed space as invalid in metadata and hold freed space from use for as long as possible. So access of freed space issue can be detected. But obviously this solution is not optimal.


As mentioned, ASAN introduces overhead and does not solve the issues well.

Memory tagging (MT) comes into rescue. For example, we can assign a 4bit tag for every 16 bytesof real data. Software uses pointer to access memory. Pointer itself also has a tag.

Memory tag and point tag are allocated by memory allocation function such as malloc(). Memory tag is freed when memory is freed. When software uses pointer to access memory, hardware will check if pointer tag matches memory tag. If not, data is discarded.

This example shows array P has 20 bytes. But since memory tagging granularity is 16 bytes, 32 bytes are assigned to P. These 32 bytes are assigned with a tag indicated by green color background. Notice other data has background of yellow, orange, and blue which means they have different tag. “//0xa000_7fff_ffff_1240” is the pointer value of P. It is a 64bit pointer. Notice its upper nibble “a” has green color. This means this upper nibble is used as pointer tag and green color indicates it has the same tag as array P. But can we re-purpose part of pointer as tag? Indeed we can, thanks to an arm AArch64 feature called top-byte-ignore. This is why Memory tagging is only available to ARM’s 64bit architecture.

For out-of-range access, since data tag and pointer tag does not match, issue can be detected. When memory is freed, memory tag is assigned and it does not match pointer tag any more so access after free issue can also be detected.


But since tag has limited number of bits, its possible two different data happens to have the same tag. The possibility of this miss detection is small. For 4 bit tag, it is 1-93.7%=6.3%. For 8bit tag, it is 1-99.6%=0.4%.

It is important to note if out-of-range access happens to within granularity, issue can not be detected since the whole granularity shares one tag.

There are several ways for system to dynamically assign tag. Most common way is to assign tag randomly.



Here is ARM’s new instruction to support MTE.



Instruction Name Format
ADDG Add with Tag ADDG <Xd/SP>, <Xn/SP>, #<uimm6>, #<uimm4>
CMPP Compare with Tag CMPP <Xn/SP>, <Xm/SP>
GMI Tag Mask Insert GMI <Xd>, <Xn/SP>, <Xm>
IRG Insert Random Tag IRG <Xd/SP>, <Xn/SP>{, <Xm>}
LDG Load Allocation Tag LDG <Xt>, [<Xn/SP>{, #<simm>}]
LDGV Load Tag Vector LDGV <Xt>, [<Xn/SP>]!
ST2G Store Allocaton Tags ST2G [<Xn/SP>], #<simm>
ST2G [<Xn/SP>, #<simm>]!
STG Store Allocation Tag STG [<Xn/SP>], #<simm>
STG [<Xn/SP>, #<simm>]!
STG [<Xn/SP>{, #<simm>}]
STGP Store Allocation Tag and Pair STGP <Xt1>, <Xt2>, [<Xn/SP>], #<imm>
STGP <Xt1>, <Xt2>, [<Xn/SP>, #<imm>]!
STGP <Xt1>, <Xt2>, [<Xn/SP>{, #<imm>}]
STGV Store Tag Vector STGV <Xt>, [<Xn/SP>]!
STZ2G Store Allocation Tags, Zeroing STZ2G [<Xn/SP>], #<simm>
STZ2G [<Xn/SP>, #<simm>]!
STZ2G [<Xn/SP>{, #<simm>}]
STZG Store Allocation Tag, Zeroing STZG [<Xn/SP>], #<simm>
STZG [<Xn/SP>, #<simm>]!
STZG [<Xn/SP>{, #<simm>}]
SUBG Subtract with Tag SUBG <Xd/SP>, <Xn/SP>, #<uimm6>, #<uimm4>
SUBP Subtract Pointer SUBP <Xd>, <Xn/SP>, <Xm/SP>
SUBPS Subtract Pointer, setting Flags SUBPS <Xd>, <Xn/SP>, <Xm/SP>




Author brief is empty
1 Comment
  1. rao_mallikarjun 11 months ago



Contact Us

Thanks for helping us better serve the community. You can make a suggestion, report a bug, a misconduct, or any other issue. We'll get back to you using your private message ASAP.



Forgot your details?