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