Posted
by
timothy
on Friday November 12, 2010 @08:06AM
from the sooper-seekrit dept.

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!"

One of my pals at NVIDIA was talking about this in a generic sense. Evidently, all of the big design houses have reverse engineering departments where they scrape down to the silicon and get things running. They never make any public info, but it's crazy what kind of logic blocks they find on silicon.

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.

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)

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?

I'm actually surprised to find out that everyone's surprised. I've been hacking routers and now work for a telco surrounded by disassembled set-top boxes, and both have serial and JTAG interfaces abundant. Many require soldering, so in that respect it's "hidden" from customers.
Maybe:
- It's often more expensive to engineer these things out of the test systems to ready for production
- and just maybe it's still actually useful especially as you peer deeper into the GHz to get more performance from an existing design.

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?

Yeah, security of DRM or TPM is probably easier to compromise (instead of taking several months to break a new DRM system it would take days since reverse engineering can be done much faster)... Which also is an obvious reason they would want to hide this feature to avoid pressure from certain groups.

It's not that I'm surprised. But you need to recall that AMD chips a goodly chunk of data/hosting-center cores, which run many clients on the same machine...
AMD will need a very good indemnification clause to wind their way out of that dammage responsibility.

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.

Just hypothethically, given the information we have from the summary, what's the worst case scenario?

- 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

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.

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.