Messages in this thread | | | Subject | Re: Is it really correct to check for breakpoint in kernel space against ptracer's address space? | From | Andy Lutomirski <> | Date | Mon, 9 May 2016 20:33:19 -0700 |
| |
On 05/09/2016 01:43 AM, Ruslan Kabatsayev wrote: > Hello all. > > Currently a 32-bit ptracer can't set HW breakpoints in tracee over > address space limitations of _tracer_. Even if the tracee is 64-bit, > doing PTRACE_POKEUSER into u_debugreg[n] with value>=0xffffe000 leads > to EINVAL (below is a test tracer program to reproduce this). At the > same time, if tracer is 64-bit, then for both 32- and 64-bit tracees > the PTRACE_POKEUSER call will succeed even if violates address space > constraints for tracee. > > I've traced this to arch_check_bp_in_kernel_space() in > arch/x86/kernel/hw_breakpoint.c, which checks the address against > TASK_SIZE, which as I understood refers to the current task, i.e. > caller of the syscall, instead of the tracee (at least tracing this in > Bochs leads me to this conclusion).
Is there any reason at all for TASK_SIZE to be different from TASK_SIZE_MAX?
/me needs to audit this stuff.
--Andy
| |