'Super-secret' debugger discovered in AMD CPUs
Password-protected feature goes beyond x86
A hardware hacker has discovered a secret debugging feature hidden in all AMD chips made in the past decade.
The password-protected debugger came as a shock to reverse-engineers who have hungered for an on-chip mechanism for performing conditional and direct-hardware breakpoint operations. Although AMD has built the firmware-controlled feature into all chips since the Athlon XP, the company kept it a closely guarded secret that was only disclosed late last week by a hacker who goes by the name Czernobyl.
“AMD processors (Athlon XP and better) have included firmware-based debugging features that expand greatly over standard, architecturally defined capabilities of x86,” the hacker wrote. “For some reason, though, AMD has been tightly secretive about these features; hint of their existence was gained by glancing at CBID's page.”
To put a chip into developer mode, a user must first enter what amounts to a password — 9C5A203A — into the CPU's EDI register. Czernobyl was able to deduce the secret setting by brute forcing the key.
Presumably, the debugger is an internal AMD utility used during development and then turned off before shipping. Its discovery by world + dog means that everyday users may have powerful new tools to hack, debug, and reverse-engineer their hardware. Now that its existence and the instructions for turning it on are known, the real discoveries about exactly what can be done with it are sure to commence. ®
COMMENTS
Nice FUD
You'd have to be running in kernel/driver developer/debug mode to get access to these from what I can see (MSR is protected). Go read about 'Ring Security' and CPU modes.
Article should have been titled
"AMD secret backdoor debuggery discovery"
Breakpoing feature...
Well, I withdrew my previous post, as it contains some stuff that wasn't the feature discussed here... That'll teach me to read the WHOLE thing before posting replies.
1. This feature allows breakpointing in a wider-range - so you can say "anyone writing to this range of memory" with a bigger granularity than 1-2-4-8 bytes as the standard x86 debug feature allows.
2. The Password in a register is used in conjunction with operations that write to some other register, typically MSR (model specific registers), so you stuff a value in ECX to indicate which MSR, another value in EAX to say what you want this register to be, and password in EDI - if you don't put the right password in EDI, it will react as if the MSR doesn't exist. So it's not just "you put a random value in a register and something happens". It just means that if you don't know the password, you can't open the door. The password is not part of the security as such - see #3.
3. As setting this feature up involve writing to MSR's, you can't just do this from any old process. It has to be in kernel mode already. Not a big security hole. If you are in kernel mode, you can do anything you like [assuming you know how - but this feature doesn't provide any further information there].
Note: I haven't worked with directly this technology, so my understanding of it is from reading the internal specifications, and my general understanding of how the processor works.
I do agree that the purpose of keeping this secret is more to do with avoiding having to support this feature (in way of backwards compatibility and requests for improvement/bug fixes) than to "prevent users from accessing it". It may also have side-effects that aren't well understood - what happens if you set a break that affects a read-modify-write operation that locks the bus, and the same memory location is used by the debugger? If it's an AMD internal functionality, then you don't have to worry about other people using it and complaining when the processor goes into an internal deadlock when it hits some special condition [not at all saying this happens - but internally used functionality can be allowed to be tested at a much lesser level than something that is used by everyone].
--
Mats
Why be so paranoid?
I have not read the tech details but I suspect this is a priviledged instruction.
Quite likely the secrecy just reduces the need to support the feature. If you tell the world about a feature then you end up getting people wanting to use it and struggling with it and then whinging when you remove it or change it. Much easier to keep quiet.
A couple of years ago I spoke with an Atmel design engineer and asked why they didn't publish the debugging spec for some of their AVR parts. Everyone knows these parts have built in debugging and any sufficiently motivated black hat could figure out the protocol (or just plug in a $30 debugger). They chose to keep the feature unpublished so that they would not have to support it.
