Re: ptrace bugs and related problems

From: Albert Cahalan
Date: Mon Jul 31 2006 - 20:31:57 EST

On 7/31/06, Chuck Ebbert <76306.1226@xxxxxxxxxxxxxx> wrote:
On Thu, 27 Jul 2006 02:55:17 -0400, Albert Cahalan wrote:

> There is also no check
> for failure, as when the popf or iret takes an alignment exception
> or hits an unmapped page.

Can that happen? Singlestep traps happen after the instruction has
already executed. Or are you talking about starting to singlestep
after hitting a code breakpoint fault?

You're at a popf that can not complete.
You single-step.
The kernel sets TF.
The kernel notes the popf.
The kernel assumes that TF will be determined by the popf.
The kernel tries to run the popf.
The popf faults, leaving TF unmodified.
The kernel fails to clear TF.

> There is the pushf problem. Single-stepping this simple code
> does not work: pushf ; popf

The debugger needs to mask TF in the pushed flags. Read the comment
in is_at_popf().

I saw the comment. I don't consider that documentation.
Why even have single-step support if the debugger has to
mess with eflags manually anyway? I might as well just
exclusively use PTRACE_SYSCALL.

I think the term is "known bug".

> The is_at_popf function on x86-64 fails to account for instruction
> set differences. Many prefixes are only valid in 32-bit mode, and
> many others are only valid in 64-bit mode.

I only see one bug here: the REX prefixes are 'inc' instructions
in compatibility mode. Otherwise, prefixes that are only valid in
32-bit mode are ignored in 64-bit mode.

Oh, OK, I thought they faulted. (AMD botched this)

There is a problem with instruction length though.
The buffer is 16 bytes long, but should be only 15.

The 0xf0 (lock) prefix is not valid for popf or iret.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at