linux-kernel - Re: ptrace bugs and related problems

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <200607310224_MC3-1-C689-D6DC@compuserve.com>
Date:	Mon, 31 Jul 2006 02:21:56 -0400
From:	Chuck Ebbert <76306.1226@...puserve.com>
To:	Albert Cahalan <acahalan@...il.com>
Cc:	Linus Torvalds <torvalds@...l.org>,
	Alan Cox <alan@...rguk.ukuu.org.uk>, Andi Kleen <ak@...e.de>,
	Arjan van de Ven <arjan@...radead.org>,
	Andrew Morton <akpm@...l.org>, Ingo Molnar <mingo@...e.hu>,
	linux-kernel <linux-kernel@...r.kernel.org>,
	Roland Dreier <roland@...hat.com>
Subject: Re: ptrace bugs and related problems

In-Reply-To: <787b0d920607262355x3f669f0ap544e3166be2dca21@...l.gmail.com>

On Thu, 27 Jul 2006 02:55:17 -0400, Albert Cahalan wrote:

> Both i386 and x86-64 PTRACE_SINGLESTEP only check for popf, not iret.
> Yes, really, iret can be used by normal apps.

Well there's a FIXME in the x86_64 code for that, anyway. (lahf/sahf
can't cause problems, so iret is the only remaining problem.)

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

> 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().

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

> The debugger has no way to reliably stop a process without causing
> confusion. The SIGSTOP signal is not queued. The app under debug might
> use SIGSTOP and rely on SIGSTOP to work. The debugger can't steal this.

I sort of got this working some time ago but I forget what the
problems were.  The idea was to decide whether or not a SIGSTOP was
meant for the debugger or not, and forward the unwanted ones to the
app.  But yeah, the interface really sucks and that probably can't be
made to work.

What Linux needs is a fresh new design for a debugging interface to
sit on top if utrace, one that solves the current inherent problems.
Just making a list of these problems is probably the place to start.

-- 
Chuck

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