lkml.org 
[lkml]   [2006]   [Jul]   [31]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: ptrace bugs and related problems
    In-Reply-To: <787b0d920607262355x3f669f0ap544e3166be2dca21@mail.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@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2006-07-31 08:31    [W:0.022 / U:32.188 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site