0001 =========================================
0002 Tagged virtual addresses in AArch64 Linux
0003 =========================================
0004
0005 Author: Will Deacon <will.deacon@arm.com>
0006
0007 Date : 12 June 2013
0008
0009 This document briefly describes the provision of tagged virtual
0010 addresses in the AArch64 translation system and their potential uses
0011 in AArch64 Linux.
0012
0013 The kernel configures the translation tables so that translations made
0014 via TTBR0 (i.e. userspace mappings) have the top byte (bits 63:56) of
0015 the virtual address ignored by the translation hardware. This frees up
0016 this byte for application use.
0017
0018
0019 Passing tagged addresses to the kernel
0020 --------------------------------------
0021
0022 All interpretation of userspace memory addresses by the kernel assumes
0023 an address tag of 0x00, unless the application enables the AArch64
0024 Tagged Address ABI explicitly
0025 (Documentation/arm64/tagged-address-abi.rst).
0026
0027 This includes, but is not limited to, addresses found in:
0028
0029 - pointer arguments to system calls, including pointers in structures
0030 passed to system calls,
0031
0032 - the stack pointer (sp), e.g. when interpreting it to deliver a
0033 signal,
0034
0035 - the frame pointer (x29) and frame records, e.g. when interpreting
0036 them to generate a backtrace or call graph.
0037
0038 Using non-zero address tags in any of these locations when the
0039 userspace application did not enable the AArch64 Tagged Address ABI may
0040 result in an error code being returned, a (fatal) signal being raised,
0041 or other modes of failure.
0042
0043 For these reasons, when the AArch64 Tagged Address ABI is disabled,
0044 passing non-zero address tags to the kernel via system calls is
0045 forbidden, and using a non-zero address tag for sp is strongly
0046 discouraged.
0047
0048 Programs maintaining a frame pointer and frame records that use non-zero
0049 address tags may suffer impaired or inaccurate debug and profiling
0050 visibility.
0051
0052
0053 Preserving tags
0054 ---------------
0055
0056 When delivering signals, non-zero tags are not preserved in
0057 siginfo.si_addr unless the flag SA_EXPOSE_TAGBITS was set in
0058 sigaction.sa_flags when the signal handler was installed. This means
0059 that signal handlers in applications making use of tags cannot rely
0060 on the tag information for user virtual addresses being maintained
0061 in these fields unless the flag was set.
0062
0063 Due to architecture limitations, bits 63:60 of the fault address
0064 are not preserved in response to synchronous tag check faults
0065 (SEGV_MTESERR) even if SA_EXPOSE_TAGBITS was set. Applications should
0066 treat the values of these bits as undefined in order to accommodate
0067 future architecture revisions which may preserve the bits.
0068
0069 For signals raised in response to watchpoint debug exceptions, the
0070 tag information will be preserved regardless of the SA_EXPOSE_TAGBITS
0071 flag setting.
0072
0073 Non-zero tags are never preserved in sigcontext.fault_address
0074 regardless of the SA_EXPOSE_TAGBITS flag setting.
0075
0076 The architecture prevents the use of a tagged PC, so the upper byte will
0077 be set to a sign-extension of bit 55 on exception return.
0078
0079 This behaviour is maintained when the AArch64 Tagged Address ABI is
0080 enabled.
0081
0082
0083 Other considerations
0084 --------------------
0085
0086 Special care should be taken when using tagged pointers, since it is
0087 likely that C compilers will not hazard two virtual addresses differing
0088 only in the upper byte.
