lkml.org 
[lkml]   [2015]   [Sep]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: Dealing with the NMI mess
    On Fri, 31 Jul 2015, Borislav Petkov wrote:

    > Yeah, INT 1. I wonder whether INT 1, i.e. CD imm8 does the same thing.
    >
    > But why do you say it is special - it simply raises #DB, i.e. vector 1.
    > Web page seems to say so when interrupt redirection is disabled. It
    > sounds like a nice and quick way to generate a breakpoint. You can do
    > that with INT 01, i.e., the CD opcode, too.
    >
    > If I'd had to guess, it isn't documented because of the proprietary ICE
    > aspect. And no one uses ICEs anymore so it is going to be forgotten with
    > people popping off and on and asking about the undocumented opcode.

    FYI, it's actually still in use with modern hardware, as a software
    breakpoint (and hence it has to be a single byte INT1 instruction rather
    than a multiple-byte regular INT 1 encoding) with JTAG probe hardware used
    for bare-metal debugging. E.g. Intel Atom supports it and boards have
    been available with a JTAG connector, which Intel calls XDP aka Extended
    Debug Port, e.g. the D945GCLF board (aka Crown Beach IIRC) had one.

    By fiddling with some bits in the CPU, which are only accessible through
    JTAG, probe firmware takes control over #DB making it trap into the debug
    mode rather than into the kernel. As noted above INT1 is used rather than
    INT3 (which still traps into the kernel with #BP as usually) for software
    breakpoints, but all the other DR0-7 resources are also available to the
    probe and the General Detect fault is used to prevent the kernel from
    fiddling with them. Similarly single-stepping traps into probe firmware.
    Debug mode transitions are completely transparent to any kernel-mode
    software run.

    I did some work on this a few years ago, including emulating DR0-7
    accesses in software down the JTAG handler upon a General Detect fault to
    keep the kernel both happy and away from real debug registers. ;) Yes,
    you can debug any software with this stuff, including the Linux kernel:
    set instruction and data breakpoints, single-step it, poke at all hardware
    registers, including descriptor registers not otherwise accessible (you
    can set funny modes for segments, also in the 64-bit mode), etc. One
    complication though is you operate on physical addresses when poking at
    memory, you can't ask the CPU's MMU to remap them for you (you can walk
    page tables manually of course, just as the MMU would).

    I hope this clears things a bit around this stuff. :) You might be able
    to find some more by issuing a query for "Extended Debug Port" with your
    favourite Internet search engine.

    It's been a while since this discussion, but I thought I'd chime in as
    you might find it interesting. I'm actually a bit surprised the knowledge
    about this is so poor among x86 experts.

    Maciej


    \
     
     \ /
      Last update: 2015-09-07 08:01    [W:3.339 / U:0.872 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site