Re: ptrace bugs and related problems

["Albert Cahalan" <acahalan@gmail.com>]

On 7/31/06, Chuck Ebbert <76306.1226@compuserve.com> 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.