Messages in this thread | | | Date | Fri, 23 Nov 2012 17:33:20 +0100 | From | Oleg Nesterov <> | Subject | Re: arch_check_bp_in_kernelspace: fix the range check |
| |
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.
| |