Re: ptrace denies access to EFLAGS_RF

[Stephane Eranian <eranian@hpl.hp.com>]

Chuck,

Thanks for the quick patch. It does fix my problem.

Note that the same problem exists on x86_64 and
the same patch should fix the problem there as well.


On Thu, Jan 05, 2006 at 11:11:29PM -0500, Chuck Ebbert wrote:
> In-Reply-To: <20060105105130.GC3712@frankl.hpl.hp.com>
> 
> On Thu, 5 Jan 2006 at 02:51:30 -0800, Stephane Eranian wrote:
> 
> > I am trying to the user HW debug registers on i386
> > and I am running into a problem with ptrace() not allowing access
> > to EFLAGS_RF for POKEUSER (see FLAG_MASK).
> > 
> > I am not sure I understand the motivation for denying access
> > to this flag which can be used to resume after a code
> > breakpoint has been reached. It avoids the need to remove the
> > breakpoint, single step, and reinstall. The equivalent
> > functionality exists on IA-64 and is allowed by ptrace().
> 
> I see no reason for denying this.  This patch should fix it:
> 
> 
> i386: PTRACE_POKEUSR: allow changing RF bit in EFLAGS register.
> 
> Setting RF (resume flag) allows a debugger to resume execution
> after a code breakpoint without tripping the breakpoint again.
> It is reset by the CPU after execution of one instruction.
> 
> Signed-off-by: Chuck Ebbert <76306.1226@compuserve.com>
> 
> --- 2.6.15a.orig/arch/i386/kernel/ptrace.c
> +++ 2.6.15a/arch/i386/kernel/ptrace.c
> @@ -32,9 +32,12 @@
>   * in exit.c or in signal.c.
>   */
>  
> -/* determines which flags the user has access to. */
> -/* 1 = access 0 = no access */
> -#define FLAG_MASK 0x00044dd5
> +/*
> + * Determines which flags the user has access to [1 = access, 0 = no access].
> + * Prohibits changing ID(21), VIP(20), VIF(19), VM(17), IOPL(12-13), IF(9).
> + * Also masks reserved bits (31-22, 15, 5, 3, 1).
> + */
> +#define FLAG_MASK 0x00054dd5
>  
>  /* set's the trap flag. */
>  #define TRAP_FLAG 0x100
> -- 
> Chuck
> Currently reading: _Thud!_ by Terry Pratchett

-- 

-Stephane
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/