Re: SYSCALL, ptrace and syscall restart breakages (Re: [RFC] weird crap with vdso on uml/i386)

Andrew Lutomirski
2011-08-22T02:26:22Z

On Sun, Aug 21, 2011 at 10:07 PM, Al Viro <viro@zeniv.linux.org.uk> wrote:
> On Sun, Aug 21, 2011 at 10:01:40PM -0400, Andrew Lutomirski wrote:
>
>>  3. We're worried that pt_regs-using compat syscalls might want the
>> regs to appear to match the actual arguments (why?)
>
> run strace and you'll see why.
>

I'm talking about the implementations of stub32_rt_sigreturn,
sys32_rt_sigreturn, stub32_sigreturn, stub32_sigaltstack,
stub32_execve, stub32_fork, stub32_clone, stub32_vfork, and stub32_iopl.
I don't know what this has to do with strace or user ABI at all.

>>  4. ptrace expects the "registers" when SYSCALL happens to match the
>> int 0x80 convention.  (This is, IMO, sick.)
>
> That's what ptrace is *for*.  It's there to let debuggers play with
> the program being debugged, including taking a look at the syscall
> arguments and modifying them.  In a predictable way, please.
>

It may be necessary, but I still think it's sick. Especially in the
case of inlined SYSCALL, where the registers reported to ptrace do not
match any register values that ever actually existed in CPU registers.
Too late to fix it, though.

Which still leaves the question of how to fix it. Restarting via an
int 0x80-based helper might be the only option that leaves everything
fully functional.

--Andy