Messages in this thread | | | Subject | Re: [RFC PATCH] ptrace: add PTRACE_GET_SYSCALL_INFO request | From | Andy Lutomirski <> | Date | Wed, 7 Nov 2018 12:20:18 -0800 |
| |
> On Nov 7, 2018, at 8:44 AM, Oleg Nesterov <oleg@redhat.com> wrote: > >> On 11/07, Andy Lutomirski wrote: >> >> >>>> On Nov 7, 2018, at 3:21 AM, Oleg Nesterov <oleg@redhat.com> wrote: >>>> >>>> On 11/07, Elvira Khabirova wrote: >>>> >>>> In short, if a 64-bit task performs a syscall through int 0x80, its tracer >>>> has no reliable means to find out that the syscall was, in fact, >>>> a compat syscall, and misidentifies it. >>>> * Syscall-enter-stop and syscall-exit-stop look the same for the tracer. >>> >>> Yes, this was discussed many times... >>> >>> So perhaps it makes sense to encode compat/is_enter in ->ptrace_message, >>> debugger can use PTRACE_GETEVENTMSG to get this info. >> >> As I said before, I strongly object to the use of “compat” here. > > Not sure I understand you... I do not like "compat" too, but this patch uses > is_compat/etc and I agree with any naming.
My point is: returning a value to user code that is:
0 if the kernel and tracee are 32-bit 0 if the kernel and tracer are 64-but 1 if the kernel is 64-bit and the tracer is 32-bit ? If the tracer is arm64 ILP32
Is not a good design. And 32-bit builds of strace will not appreciate it.
The API should return a value that, at least on a given overall architecture and preferably globally, indicates the syscall arch. While oddly named, audit_arch fits the bill nicely, and we already require it to have the right semantics for seccomp support.
| |