Slashdot Mirror
Hidden Debug Mode Found In AMD Processors
An anonymous reader writes "A hidden (and hardware password protected, by means of required special values in processor registers) debug mode has been found in AMD processors, and documented by a reverse engineer called Czernobyl on the RCE Forums community today. It enables powerful hardware debugging features long longed for by reverse engineers, such as hardware data-aware conditional breakpoints, and direct hardware 'page guard'-style breakpoints. And the best part is, it's sitting right there in your processor already, just read the details and off you go with the debugging ninja powers!"
By the way, here's a guy who does this in his spare time. He may not have the $10+ million budget that the big boys have, but it should give you a little context as to what really happens in industry.
(As the original article was instantly slashdotted, I can only guess that the AMD exploit was found through software avenues.)
http://webcache.googleusercontent.com/search?q=cache:EzsEFcoAZDAJ:www.woodmann.com/forum/archive/index.php/t-13891.html+amd+hardware+debugging+features&cd=5&hl=en&ct=clnk&gl=uk
Not necessarily. Memory access can be blocked because the MMU controls what and where an application can write, transferring control to known code (the OS) on violations. Interrupts can be blocked because invoking them gives control to the OS. Priviliged instructions can be blocked because non-ring0 execution gives control to the OS.
The OS can't choose to block for example the "xor" instructions in any reasonable way. It's possible by basically single-stepping through instructions at 100x the overhead, but it's not feasible.
Won't work at all, because you lost the '!' on the end..
Try this
Not a security hole. This debug mode is not some kind of eleet hax0r backdoor. It's for debugging the processor and microcode.
It's the OS responsibility to ensure that normal applications can't simply do whatever they like directly to the hardware, including the CPU.
IIRC, microcode updates are typically packaged as part of BIOS updates.
Tell me, how many PCs - as a percentage of those sold - get their BIOS regularly updated?
http://webcache.googleusercontent.com/search?q=cache:EzsEFcoAZDAJ:www.woodmann.com/forum/archive/index.php/t-13891.html+Czernobyl+AMD&cd=1&hl=en&ct=clnk
Intel has provided debug registers for ages. You can have up to four hardware watchpoints in pretty much any Intel - and AMD - chip. TFA is Slashdotted at the moment, but 'hardware data-aware conditional breakpoints, and direct hardware 'page guard'-style breakpoints' can both be implemented on any chip since the 386.
I am TheRaven on Soylent News
Based solely on the Google cache of the forum post describing this (linked above), there's no need to go into hysterics. For hardware and systems geeks, this is very cool. It's an extension of the existing x86 debug registers (DR0-7) that allows you to set a debug watchpoint that only fires when specific data is loaded in.
There are a lot of researchers and tool builders that would love to have this because it would allow them to take a watchpoint fault whenever they only when they have a specific value from a specific location. For instance, let's say that every so often you get a null pointer exception at a specific address. However, if you current go into gdb and set 'watch 0x{address}', you're going to take a breakpoint every single time that pointer is accessed.. Wouldn't it be great to do something like 'watch 0x{address} NULL' and only stop your debugger whenever 0 gets written into that address?
That's what the forum posts imply, at least. "Guys, I've reversed this in part... breakpoints defined in DR0 can be made to fire only on data match (under optional mask), plus masking of any or all of 12 low address bits ! Works also for I/O break points, provided CR4_DE is set, of course !"
I would wager that this is not a large security concern. Access to DR7 is restricted to ring 0, and therefore enabling debug breakpoints must be done by the operating system. While extremely interesting (I wish I could read more!), Czernobyl appears to be describing a modification to debug breakpoints that are already enabled.
Okay, the site's still down but I found a cache:
In fact, this is a fairly small incremental improvement over the existing hardware debugging support in x86 chips. It provides some extra control codes allowing the address in DR0 (one of the four registers i386 provides for hardware watchpoints) to do some slightly more clever things. For example, a watchpoint can be triggered on a partial match, rather than an exact match, to the address - this is really nice because it lets you put a watchpoint on the whole of any data structure that fits within a page. With the i386 watchpoints, you can only watch a single word with each register (4 words in total), while this means you can watch anything smaller than a page (and you can watch things bigger than a page by marking the page as no access, trapping the access, then unprotecting, single-stepping through the load / store, and continuing the process, which is how you implement watchpoints when you run out of debug registers).
I am TheRaven on Soylent News
Perhaps the slashdotted site answers this but I have to wonder why not just have a separate opcode to turn the debugging on?
Because there's already a whole bunch of privileged MSRs that normal user code mustn't have access to - many of which are undocumented and processor-specific - so adding a few more is no big deal. Adding new opcodes, on the other hand, requires more work and risks them clashing with Intel's opcode choices at a later date.
AFAIK they are packaged with every major linux distro out there, and I can't but presume that Windows ships with microcode patches as well.
A successful API design takes a mixture of software design and pedagogy.
I used to work for a processor emulator tools company called Applied Microsystems Corp, Redmond WA. now defunct.
Up thru processors type 68040 emulations tools could be mounted external to the processor chip and performed the functions mentioned ( hardware breakpoints, memory maps, all register shadowing, soft and hard breakpoints, etc, all the things that you need to perform basic computer system development. As the complexity of the systems increased beyong those early 8/16/32 bit cpu, all those hardware functions became embedded into the processor itself and are accesed by usually an I2c serial link. Emulation tools went from hardware and software complex and external to the system to hardware simple internal and software complex and external. The bottom dropped out of the eumlator tools market ( from 50k$ to 5K$ ) and that whole industry went away and got smaller and fewer in number. But the hardware tools remain inside the cpu's now, accessible by hardware licensed developers in NDA contracts. But for a few years even a few technicians had an understanding of the fine details of cpu internals. Now all that is buried again.
Except the UPS company makes that feature available for money. If AMD isn't releasing this info to anyone, then it isn't golden screwdrivering.
That is not always the case.
For example they did not properly document and release the docs on the hardware RNG in their first chipsets when it came out. As a result it ended up supported only on Linux on a "friend-of-mine" basis and MSFT (on whatever basis). The other OS developers did not know about it for a while (more than half a year). I remember personally telling Theo De Raadt on BUGTRAQ at the time to stop talking rubbish that AMD does not have a hardware RNG and he was genuinely shocked. However the fact is a fact - it was not open.
This is just an example, i can think of quite a few others.
Baker's Law: Misery no longer loves company. Nowadays it insists on it
http://www.sigsegv.cx/
Actually most of those controls, such as an ordinary user-space program just overwriting arbitrary places in physical memory or running on the CPU for as long as it wishes and not allowing anything else to preempt it, are enforced by hardware. That's the only way they can possibly work.
Not that I'm that knowledgeable about virtualization software, but I can't imagine that they would run priviledged code in the virtual machine as priviledged code on the host CPU, so it doesn't matter anyways.
In a VM running under hardware-based virtualization (AMD-V / VT-x) , privileged code in the guest generally does run at privilege level 0, also referred to as (privileged), kernel mode, or ultimate privilege. This is required to implement a protected mode operating system; a modern guest OS needs to be able to implement its kernel mode, user mode, and have the hardware implement restrictions on its user processes, typically by reducing its user processes to RING 3, or RING1 / 2, which are permission levels the OS can configure to specify the allowed privileges. However, code in the VM is running as a guest OS.
It means the guest OS must run with ultimate privilege. To address this, CPU manufacturers created a new privilege level called "ring -1". When the virtualization feature is active in hardware, the virtual machine monitor runs at ring -1, and runs guest OS code at ring 0.
As Intel puts it: VT-x and VT-i allow guest software to run at its intended privilege level. Guest software is constrained, not by privilege level, but because for VT-x it runs in VMX non-root operation
In a software-emulated VM, instructions are translated and rewritten by the hypervisors anyways, and the hypervisor itself generally runs in Ring 3 user mode not kernel mode in that case, It is up to the hypervisor to protect itself.