2013-06-12 09:28:04 -06:00
|
|
|
Tagged virtual addresses in AArch64 Linux
|
|
|
|
|
=========================================
|
|
|
|
|
|
|
|
|
|
Author: Will Deacon <will.deacon@arm.com>
|
|
|
|
|
Date : 12 June 2013
|
|
|
|
|
|
|
|
|
|
This document briefly describes the provision of tagged virtual
|
|
|
|
|
addresses in the AArch64 translation system and their potential uses
|
|
|
|
|
in AArch64 Linux.
|
|
|
|
|
|
|
|
|
|
The kernel configures the translation tables so that translations made
|
|
|
|
|
via TTBR0 (i.e. userspace mappings) have the top byte (bits 63:56) of
|
|
|
|
|
the virtual address ignored by the translation hardware. This frees up
|
arm64: documentation: document tagged pointer stack constraints
Some kernel features don't currently work if a task puts a non-zero
address tag in its stack pointer, frame pointer, or frame record entries
(FP, LR).
For example, with a tagged stack pointer, the kernel can't deliver
signals to the process, and the task is killed instead. As another
example, with a tagged frame pointer or frame records, perf fails to
generate call graphs or resolve symbols.
For now, just document these limitations, instead of finding and fixing
everything that doesn't work, as it's not known if anyone needs to use
tags in these places anyway.
In addition, as requested by Dave Martin, generalize the limitations
into a general kernel address tag policy, and refactor
tagged-pointers.txt to include it.
Fixes: d50240a5f6ce ("arm64: mm: permit use of tagged pointers at EL0")
Cc: <stable@vger.kernel.org> # 3.12.x-
Reviewed-by: Dave Martin <Dave.Martin@arm.com>
Acked-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Kristina Martsenko <kristina.martsenko@arm.com>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
2017-05-03 09:37:48 -06:00
|
|
|
this byte for application use.
|
2013-06-12 09:28:04 -06:00
|
|
|
|
|
|
|
|
|
arm64: documentation: document tagged pointer stack constraints
Some kernel features don't currently work if a task puts a non-zero
address tag in its stack pointer, frame pointer, or frame record entries
(FP, LR).
For example, with a tagged stack pointer, the kernel can't deliver
signals to the process, and the task is killed instead. As another
example, with a tagged frame pointer or frame records, perf fails to
generate call graphs or resolve symbols.
For now, just document these limitations, instead of finding and fixing
everything that doesn't work, as it's not known if anyone needs to use
tags in these places anyway.
In addition, as requested by Dave Martin, generalize the limitations
into a general kernel address tag policy, and refactor
tagged-pointers.txt to include it.
Fixes: d50240a5f6ce ("arm64: mm: permit use of tagged pointers at EL0")
Cc: <stable@vger.kernel.org> # 3.12.x-
Reviewed-by: Dave Martin <Dave.Martin@arm.com>
Acked-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Kristina Martsenko <kristina.martsenko@arm.com>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
2017-05-03 09:37:48 -06:00
|
|
|
Passing tagged addresses to the kernel
|
|
|
|
|
--------------------------------------
|
2013-06-12 09:28:04 -06:00
|
|
|
|
arm64: documentation: document tagged pointer stack constraints
Some kernel features don't currently work if a task puts a non-zero
address tag in its stack pointer, frame pointer, or frame record entries
(FP, LR).
For example, with a tagged stack pointer, the kernel can't deliver
signals to the process, and the task is killed instead. As another
example, with a tagged frame pointer or frame records, perf fails to
generate call graphs or resolve symbols.
For now, just document these limitations, instead of finding and fixing
everything that doesn't work, as it's not known if anyone needs to use
tags in these places anyway.
In addition, as requested by Dave Martin, generalize the limitations
into a general kernel address tag policy, and refactor
tagged-pointers.txt to include it.
Fixes: d50240a5f6ce ("arm64: mm: permit use of tagged pointers at EL0")
Cc: <stable@vger.kernel.org> # 3.12.x-
Reviewed-by: Dave Martin <Dave.Martin@arm.com>
Acked-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Kristina Martsenko <kristina.martsenko@arm.com>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
2017-05-03 09:37:48 -06:00
|
|
|
All interpretation of userspace memory addresses by the kernel assumes
|
2019-08-23 10:37:17 -06:00
|
|
|
an address tag of 0x00, unless the application enables the AArch64
|
|
|
|
|
Tagged Address ABI explicitly
|
|
|
|
|
(Documentation/arm64/tagged-address-abi.rst).
|
arm64: documentation: document tagged pointer stack constraints
Some kernel features don't currently work if a task puts a non-zero
address tag in its stack pointer, frame pointer, or frame record entries
(FP, LR).
For example, with a tagged stack pointer, the kernel can't deliver
signals to the process, and the task is killed instead. As another
example, with a tagged frame pointer or frame records, perf fails to
generate call graphs or resolve symbols.
For now, just document these limitations, instead of finding and fixing
everything that doesn't work, as it's not known if anyone needs to use
tags in these places anyway.
In addition, as requested by Dave Martin, generalize the limitations
into a general kernel address tag policy, and refactor
tagged-pointers.txt to include it.
Fixes: d50240a5f6ce ("arm64: mm: permit use of tagged pointers at EL0")
Cc: <stable@vger.kernel.org> # 3.12.x-
Reviewed-by: Dave Martin <Dave.Martin@arm.com>
Acked-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Kristina Martsenko <kristina.martsenko@arm.com>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
2017-05-03 09:37:48 -06:00
|
|
|
|
|
|
|
|
This includes, but is not limited to, addresses found in:
|
|
|
|
|
|
|
|
|
|
- pointer arguments to system calls, including pointers in structures
|
|
|
|
|
passed to system calls,
|
|
|
|
|
|
|
|
|
|
- the stack pointer (sp), e.g. when interpreting it to deliver a
|
|
|
|
|
signal,
|
|
|
|
|
|
|
|
|
|
- the frame pointer (x29) and frame records, e.g. when interpreting
|
|
|
|
|
them to generate a backtrace or call graph.
|
|
|
|
|
|
2019-08-23 10:37:17 -06:00
|
|
|
Using non-zero address tags in any of these locations when the
|
|
|
|
|
userspace application did not enable the AArch64 Tagged Address ABI may
|
|
|
|
|
result in an error code being returned, a (fatal) signal being raised,
|
|
|
|
|
or other modes of failure.
|
arm64: documentation: document tagged pointer stack constraints
Some kernel features don't currently work if a task puts a non-zero
address tag in its stack pointer, frame pointer, or frame record entries
(FP, LR).
For example, with a tagged stack pointer, the kernel can't deliver
signals to the process, and the task is killed instead. As another
example, with a tagged frame pointer or frame records, perf fails to
generate call graphs or resolve symbols.
For now, just document these limitations, instead of finding and fixing
everything that doesn't work, as it's not known if anyone needs to use
tags in these places anyway.
In addition, as requested by Dave Martin, generalize the limitations
into a general kernel address tag policy, and refactor
tagged-pointers.txt to include it.
Fixes: d50240a5f6ce ("arm64: mm: permit use of tagged pointers at EL0")
Cc: <stable@vger.kernel.org> # 3.12.x-
Reviewed-by: Dave Martin <Dave.Martin@arm.com>
Acked-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Kristina Martsenko <kristina.martsenko@arm.com>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
2017-05-03 09:37:48 -06:00
|
|
|
|
2019-08-23 10:37:17 -06:00
|
|
|
For these reasons, when the AArch64 Tagged Address ABI is disabled,
|
|
|
|
|
passing non-zero address tags to the kernel via system calls is
|
|
|
|
|
forbidden, and using a non-zero address tag for sp is strongly
|
|
|
|
|
discouraged.
|
arm64: documentation: document tagged pointer stack constraints
Some kernel features don't currently work if a task puts a non-zero
address tag in its stack pointer, frame pointer, or frame record entries
(FP, LR).
For example, with a tagged stack pointer, the kernel can't deliver
signals to the process, and the task is killed instead. As another
example, with a tagged frame pointer or frame records, perf fails to
generate call graphs or resolve symbols.
For now, just document these limitations, instead of finding and fixing
everything that doesn't work, as it's not known if anyone needs to use
tags in these places anyway.
In addition, as requested by Dave Martin, generalize the limitations
into a general kernel address tag policy, and refactor
tagged-pointers.txt to include it.
Fixes: d50240a5f6ce ("arm64: mm: permit use of tagged pointers at EL0")
Cc: <stable@vger.kernel.org> # 3.12.x-
Reviewed-by: Dave Martin <Dave.Martin@arm.com>
Acked-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Kristina Martsenko <kristina.martsenko@arm.com>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
2017-05-03 09:37:48 -06:00
|
|
|
|
|
|
|
|
Programs maintaining a frame pointer and frame records that use non-zero
|
|
|
|
|
address tags may suffer impaired or inaccurate debug and profiling
|
|
|
|
|
visibility.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Preserving tags
|
|
|
|
|
---------------
|
|
|
|
|
|
|
|
|
|
Non-zero tags are not preserved when delivering signals. This means that
|
|
|
|
|
signal handlers in applications making use of tags cannot rely on the
|
|
|
|
|
tag information for user virtual addresses being maintained for fields
|
|
|
|
|
inside siginfo_t. One exception to this rule is for signals raised in
|
|
|
|
|
response to watchpoint debug exceptions, where the tag information will
|
|
|
|
|
be preserved.
|
2013-06-12 09:28:04 -06:00
|
|
|
|
|
|
|
|
The architecture prevents the use of a tagged PC, so the upper byte will
|
|
|
|
|
be set to a sign-extension of bit 55 on exception return.
|
arm64: documentation: document tagged pointer stack constraints
Some kernel features don't currently work if a task puts a non-zero
address tag in its stack pointer, frame pointer, or frame record entries
(FP, LR).
For example, with a tagged stack pointer, the kernel can't deliver
signals to the process, and the task is killed instead. As another
example, with a tagged frame pointer or frame records, perf fails to
generate call graphs or resolve symbols.
For now, just document these limitations, instead of finding and fixing
everything that doesn't work, as it's not known if anyone needs to use
tags in these places anyway.
In addition, as requested by Dave Martin, generalize the limitations
into a general kernel address tag policy, and refactor
tagged-pointers.txt to include it.
Fixes: d50240a5f6ce ("arm64: mm: permit use of tagged pointers at EL0")
Cc: <stable@vger.kernel.org> # 3.12.x-
Reviewed-by: Dave Martin <Dave.Martin@arm.com>
Acked-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Kristina Martsenko <kristina.martsenko@arm.com>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
2017-05-03 09:37:48 -06:00
|
|
|
|
2019-08-23 10:37:17 -06:00
|
|
|
This behaviour is maintained when the AArch64 Tagged Address ABI is
|
|
|
|
|
enabled.
|
|
|
|
|
|
arm64: documentation: document tagged pointer stack constraints
Some kernel features don't currently work if a task puts a non-zero
address tag in its stack pointer, frame pointer, or frame record entries
(FP, LR).
For example, with a tagged stack pointer, the kernel can't deliver
signals to the process, and the task is killed instead. As another
example, with a tagged frame pointer or frame records, perf fails to
generate call graphs or resolve symbols.
For now, just document these limitations, instead of finding and fixing
everything that doesn't work, as it's not known if anyone needs to use
tags in these places anyway.
In addition, as requested by Dave Martin, generalize the limitations
into a general kernel address tag policy, and refactor
tagged-pointers.txt to include it.
Fixes: d50240a5f6ce ("arm64: mm: permit use of tagged pointers at EL0")
Cc: <stable@vger.kernel.org> # 3.12.x-
Reviewed-by: Dave Martin <Dave.Martin@arm.com>
Acked-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Kristina Martsenko <kristina.martsenko@arm.com>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
2017-05-03 09:37:48 -06:00
|
|
|
|
|
|
|
|
Other considerations
|
|
|
|
|
--------------------
|
|
|
|
|
|
|
|
|
|
Special care should be taken when using tagged pointers, since it is
|
|
|
|
|
likely that C compilers will not hazard two virtual addresses differing
|
|
|
|
|
only in the upper byte.
|
