Hi,
On 10/26/23 09:45, Kevin Brodsky wrote:
In PCuABI, {get,put}_user currently access user memory via standard 64-bit pointers. This patch switches to capability-based accesses: instead of extracting the address of the input capability, it is directly used to make the access. As a result, {get,put}_user validate the capability metadata, failing with -EFAULT if the hardware checks fail (causing a capability exception).
Unprivileged load and store instructions operating on a capability base register (e.g. ldtr/sttr x0, [c1]) are only available in the C64 ISA, we therefore need to switch to C64 before executing them (and then return to A64). We also need to use the "C" asm constraint for capability registers. This requirement has recently disappeared in Clang, but for backwards-compatibility we stick to using that constraint for now.
Because __{get,put}_mem_asm can operate on either a kernel or user pointer, fallback macros are defined for the kernel case. The Morello-specific variants that load or store a capability (__morello_raw_{get,put}_user_cap) are only passed user pointers, so the user macros can directly be used there.
Signed-off-by: Kevin Brodskykevin.brodsky@arm.com
arch/arm64/include/asm/uaccess.h | 26 ++++++++++++++++++-------- 1 file changed, 18 insertions(+), 8 deletions(-)
diff --git a/arch/arm64/include/asm/uaccess.h b/arch/arm64/include/asm/uaccess.h index c28850a79aad..5b6134066b7e 100644 --- a/arch/arm64/include/asm/uaccess.h +++ b/arch/arm64/include/asm/uaccess.h @@ -32,15 +32,21 @@ ".arch morello+c64\n" #define __ASM_SWITCH_TO_A64 " bx #4\n" \ ".arch morello\n" +#define __ASM_RO_UPTR_CONSTR "C" #define __ASM_RW_UPTR_CONSTR "+C" #else #define __ASM_SWITCH_TO_C64 #define __ASM_SWITCH_TO_A64 +#define __ASM_RO_UPTR_CONSTR "r" #define __ASM_RW_UPTR_CONSTR "+r" #endif #define __ASM_UACCESS_BEFORE __ASM_SWITCH_TO_C64 #define __ASM_UACCESS_AFTER __ASM_SWITCH_TO_A64 +#define __ASM_KACCESS_BEFORE +#define __ASM_KACCESS_AFTER +#define __ASM_RO_KPTR_CONSTR "r" +#define __ASM_RW_KPTR_CONSTR "+r"
Would it be better to move the assembly constraint macros to a more generic header? We'll need macros like these anytime we handle assembly for purecap vs aarch64; for example we defined similar macros for the vDSO fallback syscalls. Having them in a distinct header would cut down on duplication.
Best, Aditya