Re: ptrace bugs and related problems

[Chuck Ebbert <76306.1226@compuserve.com>]

In-Reply-To: <787b0d920607311730s5a951a5cv38eea7db03c759c8@mail.gmail.com>

On Mon, 31 Jul 2006 20:30:07 -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?
> 
> 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.

That can be fixed, but it won't be easy.

> > > 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 think the term is "known bug".

Well at least it's known. :)

> > > 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.
> 
> There is a problem with instruction length though.
> The buffer is 16 bytes long, but should be only 15.

OK.

> The 0xf0 (lock) prefix is not valid for popf or iret.

I think it is OK on really old processors (maybe only 386?)  If we fix
the above problem with faulting instructions then the fault this would
cause on newer CPUs should not be a problem.
-- 
Chuck

-
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/