tagged-pointers.rst

 1=========================================
 2Tagged virtual addresses in AArch64 Linux
 3=========================================
 4
 5Author: Will Deacon <will.deacon@arm.com>
 6
 7Date  : 12 June 2013
 8
 9This document briefly describes the provision of tagged virtual
10addresses in the AArch64 translation system and their potential uses
11in AArch64 Linux.
12
13The kernel configures the translation tables so that translations made
14via TTBR0 (i.e. userspace mappings) have the top byte (bits 63:56) of
15the virtual address ignored by the translation hardware. This frees up
16this byte for application use.
17
18
19Passing tagged addresses to the kernel
20--------------------------------------
21
22All interpretation of userspace memory addresses by the kernel assumes
23an address tag of 0x00, unless the application enables the AArch64
24Tagged Address ABI explicitly
25(Documentation/arch/arm64/tagged-address-abi.rst).
26
27This includes, but is not limited to, addresses found in:
28
29 - pointer arguments to system calls, including pointers in structures
30   passed to system calls,
31
32 - the stack pointer (sp), e.g. when interpreting it to deliver a
33   signal,
34
35 - the frame pointer (x29) and frame records, e.g. when interpreting
36   them to generate a backtrace or call graph.
37
38Using non-zero address tags in any of these locations when the
39userspace application did not enable the AArch64 Tagged Address ABI may
40result in an error code being returned, a (fatal) signal being raised,
41or other modes of failure.
42
43For these reasons, when the AArch64 Tagged Address ABI is disabled,
44passing non-zero address tags to the kernel via system calls is
45forbidden, and using a non-zero address tag for sp is strongly
46discouraged.
47
48Programs maintaining a frame pointer and frame records that use non-zero
49address tags may suffer impaired or inaccurate debug and profiling
50visibility.
51
52
53Preserving tags
54---------------
55
56When delivering signals, non-zero tags are not preserved in
57siginfo.si_addr unless the flag SA_EXPOSE_TAGBITS was set in
58sigaction.sa_flags when the signal handler was installed. This means
59that signal handlers in applications making use of tags cannot rely
60on the tag information for user virtual addresses being maintained
61in these fields unless the flag was set.
62
63If FEAT_MTE_TAGGED_FAR (Armv8.9) is supported, bits 63:60 of the fault address
64are preserved in response to synchronous tag check faults (SEGV_MTESERR)
65otherwise not preserved even if SA_EXPOSE_TAGBITS was set.
66Applications should interpret the values of these bits based on
67the support for the HWCAP3_MTE_FAR. If the support is not present,
68the values of these bits should be considered as undefined otherwise valid.
69
70For signals raised in response to watchpoint debug exceptions, the
71tag information will be preserved regardless of the SA_EXPOSE_TAGBITS
72flag setting.
73
74Non-zero tags are never preserved in sigcontext.fault_address
75regardless of the SA_EXPOSE_TAGBITS flag setting.
76
77The architecture prevents the use of a tagged PC, so the upper byte will
78be set to a sign-extension of bit 55 on exception return.
79
80This behaviour is maintained when the AArch64 Tagged Address ABI is
81enabled.
82
83
84Other considerations
85--------------------
86
87Special care should be taken when using tagged pointers, since it is
88likely that C compilers will not hazard two virtual addresses differing
89only in the upper byte.