Hello Amnon, I am a bit confused,
On 11/23, Amnon Shiloh wrote: > > What I discovered now, is that PTRACE_SYSCALL (also PTRACE_SINGLESTEP) > does not work within the vsyscall page, so I cannot trap the kernel-calls > there (this is very simple to verify using "gdb" or "strace"). Sure, but we alredy discussed this? Once again, PTRACE_SYSCALL should work in the NATIVE mode. Obviously it won't work in EMULATE mode but we can change emulate_vsyscall() to report TRAP_VSYSCALL or even introduce PTRACE_EVENT_VSYSCALL. > The necessary patch was already discussed and is very simple. Do you mean TRAP_VSYSCALL/PTRACE_EVENT_VSYSCALL above or additional in_gate_area_no_mm() check to allow the hw bp? > Or, there is an alternative: if only I (the ptracer or the traced process) > was allowed to munmap the vsyscall page, It is not possible to unmap it. The kernel (swapper_pg_dir) has this mapping, not the process. Unlike vdso. IOW, you can only "unmap" it globally and obviously you can't do this from the userspace. Oleg. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
