Re: PTRACE_SYSCALL && vsyscall (Was: arch_check_bp_in_kernelspace: fix the range check)

[Oleg Nesterov <oleg@redhat.com>]

On 12/03, u3557@miso.sublimeip.com wrote:
>
> > However. Of course it would be nice to avoid the new option. IMO it
> > would be better to do nothing ;) vsyscall is deprecated, and EMULATE
> > is x86-specific.
>
> The problem is that the current static glibc invokes the vsyscall page,

Yes I know.

Still I'd like to avoid to change the ptrace API, even if the change is
simple. This emulate_vsyscall() is too "exotic" imho.

> > You forgot again that EMULATE does not execute the code in the
> > vsyscall page.
>
> The beauty of using the x86 debug-registers, is that they do not
> trap the instruction, but rather the fact that the program-counter
> has a given value.

Yes, I understand, so DR_RW_EXECUTE should probably work. And I even
sent the patch (untested/uncompiled). But given that even the simple
bugfix which started this thread was ignored by maintainers, I am
not sure how we can convince them this change makes sense ;)

However. This looks like a hack to me, because this code is never
executed. But this is sudjective and I am not saying this can't work.
And yes, this doesn't add new ptrace hacks.



But If we want to allow to trace vsyscall's, hw bp doesn't look very
nice imo. HBP_NUM = 4 and you need to setup 3 bp's to trace them all.

And what about strace? It won't be easy to change it to use hwbp.


That is why I think PTRACE_SYSCALL should "simply work" somehow. And
so far I think that "just report syscall_exit with orig_ax = -1" is
the best (and simple) solution.

OK. We can do more. We can report both syscall_enter/exit and we can
change orig_ax/ax temporary to "fool" the tracer, so that everything
will look as a "normal" syscall. Like vsyscall_seccomp() does.

But this needs much more changes.

Oleg.