Messages in this thread | | | From | Keno Fischer <> | Date | Tue, 19 May 2020 04:37:34 -0400 | Subject | Re: arm64: Register modification during syscall entry/exit stop |
| |
Hi Will,
> Yes, we inherited this from ARM and I think strace relies on it. In > hindsight, it is a little odd, although x7 is a parameter register in the > PCS and so it won't be live on entry to a system call.
I'm not familiar with the PCS acronym, but I assume you mean the calling convention? You have more faith in userspace than I do ;). For example, cursory googling brought up this arm64 syscall definition in musl:
https://github.com/bminor/musl/blob/593caa456309714402ca4cb77c3770f4c24da9da/arch/aarch64/syscall_arch.h
The constraints on those asm blocks allow the compiler to assume that x7 is preserved across the syscall. If a ptracer accidentally modified it (which is easy to do in the situations that I mentioned), it could absolutely cause incorrect execution of the userspace program.
> Although the examples you've > listed above are interesting, I don't see why x7 is important in any of > them (and we only support up to 6 system call arguments).
It's not so much that x7 is important, it's that lying to the ptracer is problematic, because it might remember that lie and act on it later. I did run into exactly this problem, where my ptracer accidentally changed the value of x7 and caused incorrect execution in the tracee (now that incorrect execution happened to be an assertion, because my application is paranoid about these kinds of issues, but it was incorrect nevertheless)
If it would be helpful, I can code up the syscall entry -> signal trap example ptracer to have a concrete example.
Keno
| |