Hi Catalin,
On 4/21/20 11:25 AM, Catalin Marinas wrote:
Add support for bulk setting/getting of the MTE tags in a tracee's
address space at 'addr' in the ptrace() syscall prototype. 'data' points
to a struct iovec in the tracer's address space with iov_base
representing the address of a tracer's buffer of length iov_len. The
tags to be copied to/from the tracer's buffer are stored as one tag per
byte.
On successfully copying at least one tag, ptrace() returns 0 and updates
the tracer's iov_len with the number of tags copied. In case of error,
either -EIO or -EFAULT is returned, trying to follow the ptrace() man
page.
Note that the tag copying functions are not performance critical,
therefore they lack optimisations found in typical memory copy routines.
Signed-off-by: Catalin Marinas <catalin.marinas@xxxxxxx>
Cc: Will Deacon <will@xxxxxxxxxx>
Cc: Alan Hayward <Alan.Hayward@xxxxxxx>
Cc: Luis Machado <luis.machado@xxxxxxxxxx>
Cc: Omair Javaid <omair.javaid@xxxxxxxxxx>
---
Notes:
New in v3.
arch/arm64/include/asm/mte.h | 17 ++++
arch/arm64/include/uapi/asm/ptrace.h | 3 +
arch/arm64/kernel/mte.c | 127 +++++++++++++++++++++++++++
arch/arm64/kernel/ptrace.c | 15 +++-
arch/arm64/lib/mte.S | 50 +++++++++++
5 files changed, 211 insertions(+), 1 deletion(-)
I started working on MTE support for GDB and I'm wondering if we've
already defined a way to check for runtime MTE support (as opposed to a
HWCAP2-based check) in a traced process.
Originally we were going to do it via empty-parameter ptrace calls, but
you had mentioned something about a proc-based method, if I'm not mistaken.
Regards,
Luis
