Will Deacon | d50240a | 2013-06-12 16:28:04 +0100 | [diff] [blame] | 1 | Tagged virtual addresses in AArch64 Linux |
| 2 | ========================================= |
| 3 | |
| 4 | Author: Will Deacon <will.deacon@arm.com> |
| 5 | Date : 12 June 2013 |
| 6 | |
| 7 | This document briefly describes the provision of tagged virtual |
| 8 | addresses in the AArch64 translation system and their potential uses |
| 9 | in AArch64 Linux. |
| 10 | |
| 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 |
| 13 | the virtual address ignored by the translation hardware. This frees up |
Kristina Martsenko | e6b8f5a | 2017-05-03 16:37:48 +0100 | [diff] [blame] | 14 | this byte for application use. |
Will Deacon | d50240a | 2013-06-12 16:28:04 +0100 | [diff] [blame] | 15 | |
Will Deacon | d50240a | 2013-06-12 16:28:04 +0100 | [diff] [blame] | 16 | |
Kristina Martsenko | e6b8f5a | 2017-05-03 16:37:48 +0100 | [diff] [blame] | 17 | Passing tagged addresses to the kernel |
| 18 | -------------------------------------- |
Will Deacon | d50240a | 2013-06-12 16:28:04 +0100 | [diff] [blame] | 19 | |
Kristina Martsenko | e6b8f5a | 2017-05-03 16:37:48 +0100 | [diff] [blame] | 20 | All interpretation of userspace memory addresses by the kernel assumes |
| 21 | an address tag of 0x00. |
| 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. |
Will Deacon | d50240a | 2013-06-12 16:28:04 +0100 | [diff] [blame] | 56 | |
| 57 | The architecture prevents the use of a tagged PC, so the upper byte will |
| 58 | be set to a sign-extension of bit 55 on exception return. |
Kristina Martsenko | e6b8f5a | 2017-05-03 16:37:48 +0100 | [diff] [blame] | 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. |