Documentation/arm64/tagged-pointers.rst

   1 =========================================
   2 Tagged virtual addresses in AArch64 Linux
   3 =========================================
   4
   5 Author: Will Deacon <will.deacon@arm.com>
   6
   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
  16 this byte for application use.
  17
  18
  19 Passing tagged addresses to the kernel
  20 --------------------------------------
  21
  22 All interpretation of userspace memory addresses by the kernel assumes
  23 an address tag of 0x00, unless the application enables the AArch64
  24 Tagged Address ABI explicitly
  25 (Documentation/arm64/tagged-address-abi.rst).
  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
  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.
  42
  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.
  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
  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.
  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.
  78
  79 This behaviour is maintained when the AArch64 Tagged Address ABI is
  80 enabled.
  81
  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.