aboutsummaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
Diffstat (limited to 'Documentation/arm64/tagged-pointers.txt')
-rw-r--r--Documentation/arm64/tagged-pointers.txt62
1 files changed, 47 insertions, 15 deletions
diff --git a/Documentation/arm64/tagged-pointers.txt b/Documentation/arm64/tagged-pointers.txt
index d9995f1f51b3..a25a99e82bb1 100644
--- a/Documentation/arm64/tagged-pointers.txt
+++ b/Documentation/arm64/tagged-pointers.txt
@@ -11,24 +11,56 @@ in AArch64 Linux.
11The kernel configures the translation tables so that translations made 11The kernel configures the translation tables so that translations made
12via TTBR0 (i.e. userspace mappings) have the top byte (bits 63:56) of 12via TTBR0 (i.e. userspace mappings) have the top byte (bits 63:56) of
13the virtual address ignored by the translation hardware. This frees up 13the virtual address ignored by the translation hardware. This frees up
14this byte for application use, with the following caveats: 14this byte for application use.
15 15
16 (1) The kernel requires that all user addresses passed to EL1
17 are tagged with tag 0x00. This means that any syscall
18 parameters containing user virtual addresses *must* have
19 their top byte cleared before trapping to the kernel.
20 16
21 (2) Non-zero tags are not preserved when delivering signals. 17Passing tagged addresses to the kernel
22 This means that signal handlers in applications making use 18--------------------------------------
23 of tags cannot rely on the tag information for user virtual
24 addresses being maintained for fields inside siginfo_t.
25 One exception to this rule is for signals raised in response
26 to watchpoint debug exceptions, where the tag information
27 will be preserved.
28 19
29 (3) Special care should be taken when using tagged pointers, 20All interpretation of userspace memory addresses by the kernel assumes
30 since it is likely that C compilers will not hazard two 21an address tag of 0x00.
31 virtual addresses differing only in the upper byte. 22
23This includes, but is not limited to, addresses found in:
24
25 - pointer arguments to system calls, including pointers in structures
26 passed to system calls,
27
28 - the stack pointer (sp), e.g. when interpreting it to deliver a
29 signal,
30
31 - the frame pointer (x29) and frame records, e.g. when interpreting
32 them to generate a backtrace or call graph.
33
34Using non-zero address tags in any of these locations may result in an
35error code being returned, a (fatal) signal being raised, or other modes
36of failure.
37
38For these reasons, passing non-zero address tags to the kernel via
39system calls is forbidden, and using a non-zero address tag for sp is
40strongly discouraged.
41
42Programs maintaining a frame pointer and frame records that use non-zero
43address tags may suffer impaired or inaccurate debug and profiling
44visibility.
45
46
47Preserving tags
48---------------
49
50Non-zero tags are not preserved when delivering signals. This means that
51signal handlers in applications making use of tags cannot rely on the
52tag information for user virtual addresses being maintained for fields
53inside siginfo_t. One exception to this rule is for signals raised in
54response to watchpoint debug exceptions, where the tag information will
55be preserved.
32 56
33The architecture prevents the use of a tagged PC, so the upper byte will 57The architecture prevents the use of a tagged PC, so the upper byte will
34be set to a sign-extension of bit 55 on exception return. 58be set to a sign-extension of bit 55 on exception return.
59
60
61Other considerations
62--------------------
63
64Special care should be taken when using tagged pointers, since it is
65likely that C compilers will not hazard two virtual addresses differing
66only in the upper byte.