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!"
don't they reveal this to the users?
can you harden the processors from the Slashdot effect?
That sucking sound you hear is my bandwidth.
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.
Apparently the debugging process doesn't help to combat the effects of a thorough slashdotting.
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?
Since TFA is down by now, and I can't get the exact details... does this mean that any program running and setting the right bits in the right registers can get "processor root" access to everything the processor does, irrespective of any security constraint the OS may place on that process? Oh dear
Experiments and other stuff
To state the obvious: Chernobyl, or Czernobyl as is referred to in the polish language, is a very well known nuclear disaster site. Those crafty Polish are starting to make a name for themselves in the computer industry.
A morning without coffee is like something without something else.
Hidden for a reason? Do they not want Nvidia to see this?
He who knows best knows how little he knows. - Thomas Jefferson
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.
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
So this could be enabled in the kernel and/or gcc/gdb in the near future? That would be convenient for debugging. Unfortunately the link is still blocked, so the details on enabling this is still hidden.
!
+0rc was one of the better ones, also. Very outdated nowdays but I still have a bunch of his tutorials around here somewhere...
C|N>K
I'm not suggesting this is a JTAG interface, perhaps my title is misleading. I'm suggesting it's "hidden" in the same way these hardware debug interfaces (both standardised like JTAG or other more obscure interfaces) appear "hidden" to people who don't do hardware/firmware mods. As I mentioned in the first line, I'm surprised everyone's surprised, these are immensely complex parts that sometimes need a root-of-roots, this sounds like just the thing AMD or any other manufacturer would have designed in.
I can think of many reasons why it might be hidden. For example, it may be hidden because the cost of supporting it would outweigh the benefits of admitting the "feature" is there. I don't just mean in terms of documenting it and releasing that info for developers, I mean in termins of testing it for security reasons. Plus, let us say that a theoretical bug is found that creates a hole someone can exploit - is it patchable? It's a whole can of worms AMD may be right to avoid opening.
+1 IDisagreeSoHeMustBeATrollOrAnAstroturferOrAShill
Won't work at all, because you lost the '!' on the end..
Try this
And how do you know some top black hats don't already know about this for years and have already exploits for it? It's a classic example of security through obscurity.
If it's not safe (and if it's baldly tested, it is), I'd expect AMD to disable it on a physical level, not leave it there "hidden" for someone with poor intentions to find out.
Dilbert RSS feed
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
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.
I'd say password protected and undocumented is far more hidden than a unpopulated footprint marked 'jtag' (I know I know, not all hardware debug i/faces are always that obvious either :-)
But yeah, no one should be particularly surprised... these are ridiculously complex chips and would be impossible to develop and debug (the chip that is, not software for it) without extra hidden circuitry.
SlashDot's link hygiene system doesn't recognize exclamation marks at the end of a URL as being part of the URL - notice that " [nyud.net]" has been inserted by /..
char*f="char*f=%c%s%c;main(){printf(f,34,f,34);}";main(){printf(f,34,f,34);}
I can think of many reasons why it might be hidden. For example, it may be hidden because the cost of supporting it would outweigh the benefits of admitting the "feature" is there. I don't just mean in terms of documenting it and releasing that info for developers, I mean in termins of testing it for security reasons.
...and, if it's documented as an architectural feature rather than a feature of a particular processor or line of processors, guaranteeing that it works the same in future processors, even if they have a different microarchitecture. (And even if you explicitly document it as a feature of a particular processor, if you don't implement it the same way in your next generation of processors, somebody will probably have ignored the "this is a feature specific to the Phenom 666" note in the documentation and written Whizzo-Debug using the feature, assuming that any unknown AMD processor will support it, and will whine piteously if the Phenom 3000 fails to implement it in the exact same fashion.)
Methinks this could be very useful in defeating many types of DRM. I'm thinking in particular DRM implementations similar to CSS, AACS, BD+, etc. Could this spell the end of DRM for once and for all? One can hope! Any experts care to elaborate (I'm no software developer nor a CPU engineer)?
Never argue with idiots, they just drag you down to their level then beat you with experience.
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/
it still meets the open sesame requirements of the NSA.
Could this be the Chinese hardware back door everyone is worried about?
There may be no "I" in team, but there's also no "F" in way.
I have no mod points ATM, and even if I did, well, you're already modded up as high as possible. So, I'll simply say, thank you.
Remember Robert Collins and how he reverse engineered the ICE mode of old Intel processors?
Integrated circuits have had "stealth" debug/test modes since forever. Every single one made since the 1970s on with any complexity above that of a RAM has had these modes.
When I worked for Intel I used these extensively to get "inside access" to the raw memory array for production line testing of EPROMs.
The same types of modes are how the 486DX, 486SX and 486FX (FPU) all originated from the same, exact, single-design die. Basically you go into the test mode and blow a fuse that shut down the failing half of a DX to result in an SX or FX part. All the same exact die in all cases.
The article author is way late to the party!
Since they execute your code directly on the host processor, they most certainly do work that way.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"