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

2013-01-14 Thread Oleg Nesterov
On 01/14, u3...@miso.sublimeip.com wrote: > > So here again is the patch that I need so badly - clearly it fixes a bug > and harms nobody: > > --- > diff -Naur before/arch/x86/kernel/hw_breakpoint.c > after/arch/x86/kernel/hw_break

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

2013-01-13 Thread u3557
Hi, > I would not say this is a bug but let me repeat, no need to convince me. > > Please feel free to re-send the patch(es) I sent to maintainers. Sorry, > I can't push these changes into Linus's tree. So here again is the patch that I need so badly - clearly it fixes a bug and harms nobody: --

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

2013-01-12 Thread Oleg Nesterov
On 01/10, u3...@miso.sublimeip.com wrote: > > Hi Everyone, > > > On 01/08, Pedro Alves wrote: > >> > >> On 12/04/2012 05:59 PM, Oleg Nesterov wrote: > >> > >> > 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 th

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

2013-01-09 Thread u3557
Hi Everyone, > On 01/08, Pedro Alves wrote: >> >> On 12/04/2012 05:59 PM, Oleg Nesterov wrote: >> >> > 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. >> >> Irrespective of the whole syscall tracing iss

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

2013-01-09 Thread Oleg Nesterov
On 01/08, Pedro Alves wrote: > > On 12/04/2012 05:59 PM, Oleg Nesterov wrote: > > > 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. > > Irrespective of the whole syscall tracing issue, allowing HW bkpts i

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

2013-01-08 Thread Pedro Alves
On 12/04/2012 05:59 PM, Oleg Nesterov wrote: > 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. Irrespective of the whole syscall tracing issue, allowing HW bkpts in the vsyscall just seems like a bug fix

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

2012-12-05 Thread u3557
Dear Jan, > x86 debug registers are already very scarce. Besides that userland > applications know they have 4 of them available so it would also break > them. If a userland application wants to cheat, then it has no need to bypass the debug registers: even if there were 4096 of them, covering t

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

2012-12-05 Thread Jan Kratochvil
On Sun, 02 Dec 2012 20:30:58 +0100, Oleg Nesterov wrote: > Yes, that is why I said this needs the new option. I do not mind new options although personally I do not find them meaningful for an already deprecated ABI compatibility-only issue. > If the tracer does PTRACE_SYSCALL the tracee reports

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

2012-12-04 Thread u3557
Dear Oleg, > 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 ;) Just to confi

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

2012-12-04 Thread Oleg Nesterov
On 12/03, u3...@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.

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

2012-12-02 Thread u3557
Hi Oleg, > 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, so statically-linked 3rd-party executables that were dis

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

2012-12-02 Thread Oleg Nesterov
Amnon, sorry for delay... On 11/26, Amnon Shiloh wrote: > > > Why do you need to _prevent_, say, sys_gettimeofday()? Why we can't > > change emulate_vsyscall() to respect PTRACE_SYSCALL and report > > TRAP_VSYSCALL or PTRACE_EVENT_VSYSCALL as I tried to suggest in > > http://marc.info/?l=linux-ker