lkml.org 
[lkml]   [2016]   [May]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: Is it really correct to check for breakpoint in kernel space against ptracer's address space?
From
Date
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

\
 
 \ /
  Last update: 2016-05-10 06:01    [W:0.056 / U:2.392 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site