Re: Dealing with the NMI mess

From: Maciej W. Rozycki
Date: Mon Sep 07 2015 - 01:39:44 EST

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.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at