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 always supported AMD for being cheap and open, directly approaching people. Now I'd like to know why this nice feature was hidden? Is it dangerous by enabling more powerful rootkits? I'm not going to believe that M$ wanted this hidden, or that they knew about it. So, why hidden? It helps developers a lot.
#
#\ @ ? Colonize Mars
#
http://www.woodmann.com.nyud.net/collaborative/knowledge/index.php/Super-secret_debug_capabilities_of_AMD_processors_!
may not work until SOMEBODY uses the coral cache and is able to see the site (and thus cache it for the first time)
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
+Fravia is dead, long live +Fravia.
Get an "highball" glass (cylindrical "milk" glass: holds about
200-285 ml.)
- Two ice cubes
- Dry Martini from Martini Rossi (1/3 glass)
- Wodka Moskowskaia (only russian Wodka will do) (1/3 glass)
- Schweppes Indian Tonic (1/3) glass
- Lemon zest (from Malta???)
- Green Olive (from Tuskany ???)
Sip slowly, look at the data, meditate, crack anything in sight.
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.
!
It's worth noting that this feature has been
long longed for by people longer than very long instruction words and long long integers in C.
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.
Someone will find something similar in Intel chips as well.
Maybe Computers will never be as intelligent as Humans.
For sure they won't ever become so stupid. [VR-1988]
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
It seems that the discovered functionality is about extending standard hardware watch feature with ability to match actual data being accessed, not only address.
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.
It appears the site is now down so the details of the story aren't readily available. This has some major implications for those concerned about security as mentioned by many of the above. AMD is going to have to address this because they need to close that off or it could spell major trouble for AMD as a company and a vast majority of users.
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.
"...long longed for by reverse engineers..."?
Shouldn't it be the features were long longed for by reverse engineering engineers? :)
Yeah, the extra "long" is redundant and I don't know if I've ever heard the term "reverse engineers" used to describe people who do reverse engineering. That sounds more like a person who does the opposite of engineering.
Results from the "TOPCODER" competition:
"...these competitions were dominated at their start in 2001 by Americans, but that's no longer the case -- not by a long shot. In fact, of the four Americans who won the top seats out of 4,500 contestants... By contrast, there were eight from Russia, and four each from Norway and China. The biggest delegation -- 11 -- came from Poland.... Much of Poland's abundant interest in coding contests can be traced to Tomasz Czajka, who as a multiple TopCoder champion has won more than $100,000 in prize money since the competition began. That has made him something of a national hero back home, and other students have been eager to follow suit."
From -> http://online.wsj.com/public/article/SB114721319725548216-EPUotRD8d3aZ4HFijEN8r_DOdJQ_20070509.html?mod=blogs
(So, they've already "been there, & done that", and pretty handily)
APK
P.S.=> Polish here myself, by the by... apk
Turns out they implemented an entire flight simulator in hardware :P
Monstar L
debug
>NSA
NSA mode is ON
NSA>load spyware
Spyware loaded
NSA>exit
Affirmative
>
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.
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.
look like putting 0x9c5a203a in edi on AMD cpu is know from years. Just google for it.
For example it is already used in linux kernel for workaround
Ever heard of "Design for Testability" (DFT)? I am surprised that no one on Slashdot is even aware of this.
The department of redundancy department would like a word with the article submitter!
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.'"