diff options
Diffstat (limited to 'Documentation/arm64/tagged-pointers.txt')
-rw-r--r-- | Documentation/arm64/tagged-pointers.txt | 62 |
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. | |||
11 | The kernel configures the translation tables so that translations made | 11 | The kernel configures the translation tables so that translations made |
12 | via TTBR0 (i.e. userspace mappings) have the top byte (bits 63:56) of | 12 | via TTBR0 (i.e. userspace mappings) have the top byte (bits 63:56) of |
13 | the virtual address ignored by the translation hardware. This frees up | 13 | the virtual address ignored by the translation hardware. This frees up |
14 | this byte for application use, with the following caveats: | 14 | this 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. | 17 | Passing 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, | 20 | All interpretation of userspace memory addresses by the kernel assumes |
30 | since it is likely that C compilers will not hazard two | 21 | an address tag of 0x00. |
31 | virtual addresses differing only in the upper byte. | 22 | |
23 | This 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 | |||
34 | Using non-zero address tags in any of these locations may result in an | ||
35 | error code being returned, a (fatal) signal being raised, or other modes | ||
36 | of failure. | ||
37 | |||
38 | For these reasons, passing non-zero address tags to the kernel via | ||
39 | system calls is forbidden, and using a non-zero address tag for sp is | ||
40 | strongly discouraged. | ||
41 | |||
42 | Programs maintaining a frame pointer and frame records that use non-zero | ||
43 | address tags may suffer impaired or inaccurate debug and profiling | ||
44 | visibility. | ||
45 | |||
46 | |||
47 | Preserving tags | ||
48 | --------------- | ||
49 | |||
50 | Non-zero tags are not preserved when delivering signals. This means that | ||
51 | signal handlers in applications making use of tags cannot rely on the | ||
52 | tag information for user virtual addresses being maintained for fields | ||
53 | inside siginfo_t. One exception to this rule is for signals raised in | ||
54 | response to watchpoint debug exceptions, where the tag information will | ||
55 | be preserved. | ||
32 | 56 | ||
33 | The architecture prevents the use of a tagged PC, so the upper byte will | 57 | The architecture prevents the use of a tagged PC, so the upper byte will |
34 | be set to a sign-extension of bit 55 on exception return. | 58 | be set to a sign-extension of bit 55 on exception return. |
59 | |||
60 | |||
61 | Other considerations | ||
62 | -------------------- | ||
63 | |||
64 | Special care should be taken when using tagged pointers, since it is | ||
65 | likely that C compilers will not hazard two virtual addresses differing | ||
66 | only in the upper byte. | ||