Hidden Debug Mode Found In AMD Processors 154
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!"
Why... (Score:1, Interesting)
Just a matter of time... (Score:5, Interesting)
These exist on "all processors" as ways to test the processors and increase yield cheaply. The moment that the engineering samples go out, competitors get their hands on them, and it's only days or weeks before they figure out what's really going on. Kind of cat-and-mouse.
Re:Oops, slashdotted! (Score:3, Interesting)
yea, why stories continue to be posted with direct links instead of using things like coral cache is beyond me. If you KNOW the site you are going to link to can't handle a slashdot load then DON'T LINK DIRECTLY TO IT.
Of course this does not include sadistic evil people who enjoy watching websites crash and burn (probably a sizable but not large percentage portion of the slashdot community)
Security? (Score:5, Interesting)
I wondered the same thing - if these debug features are useful to developers debugging their own software, why not market this as a feature? The only thing that occurred to me, is that, maybe there is some sort of security problem with this debug functionality? Does anyone know - could these debug features be used to do something like break Operating System security models, leading to privilege escalation issues, or for other nefarious purposes?
So it's a software JTAG (Score:5, Interesting)
Re:Security? (Score:4, Interesting)
It is possible that the debug features are for their internal use and they don't quite work as intended. They may be useful as such, but if there are implementation bugs that require cumbersome work-arounds on the software side, it may be that they are waiting for a non-buggy implementation before publically documenting the features.
It is also possible that they don't want to put the resources to documenting and supporting the debug features. After all, AMD is a small company compared to Intel and not that profitable. They even had some layoffs during the worst recession - what if they had to lay off the guys responsible for the debug mode?
Re:Security? (Score:1, Interesting)
Re:The ultimate security disaster? (Score:3, Interesting)
Re:So it's a software JTAG (Score:1, Interesting)
It's not the same thing. Virtually every microcontroller has JTAG support and nobody would be surprised to find a JTAG interface in an embedded device. It would be very well documented in the datasheets. It's no big deal to find an unpopulated serial or JTAG header in a production device. These aren't manufacturer secrets -- they are well-known debugging interfaces provided for the benefit of the device developer.
AMD's proprietary debugging features are a different story -- features not intended for the end-user to have access to and which can have a serious impact on privacy and security. This has nothing to do with extracting performance and everything to do with reverse engineering software.
Frankly it sounds like you've been "around" these sorts of things but not had much first-hand experience working with them. Imagining a device has a hardware debugger and actually finding an undocumented one are two very different things.
Re:The ultimate security disaster? (Score:2, Interesting)
- The debugmode is worthy of its name, i.e. can bypass any ring and OS restriction
- It cannot be turned on or off in the bios or with a pin, since it is undocumented
- It is on by default
- The bit combination to set resides in usual working registers and can be triggered by usual computation by native code or in any bytecode interpreter (javascript, java etc.) of your choice when carefully targeting the bytecode interpreter
Re:Security? (Score:5, Interesting)
If flipping the processor into a new mode allows you to get out of the virtual machine and pwn the Host too, then yes it makes a difference.
Re:google cache of the article (Score:3, Interesting)
And the documentation about the new opcode is probably this one:
http://cbid.softnology.biz/html/undocmsrs.html [softnology.biz]
Re:Security? (Score:3, Interesting)
Exactly, it's probably a bit of a kludge, and making it into a stable, documented, supported feature is going to be expensive with a lot of support and a small user base.
I have modes like this in some of my own products, and sometimes I'm leery of even having some other people on my own team have access to the debug modes, because of the potential for disaster and a WHOLE lot of handholding from me.
It's not worth the time it would take for me to set it up for broader use, and if I did, they would break things and then come running to me.
Re:Security? (Score:2, Interesting)
If an OS running on real hardware can block this call coming from user-mode then a hypervisor can block it coming from a VM. And if it can't be blocked you're p0wned either way. A virtual machine makes no difference.