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