My next development workstation will be AMD based. This will make writing hardware drivers so much easier.
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- …
...instead of a dedicated set of pins and a special board, AMD put simple on-chip diagnostics in there that could be used during manufacturing or perhaps after the die is cast to confirm full chip functionality (or bin the chip appropriately if less than 100% functionality is still OK). bfd.
I am sure the secrecy involves security. If a simple instruction can provide access to the internal chip, then no security software would be worth snot.
I am and have been an AMD fan for a long time, but the publishing of this info could very well jeopardize my systems' security, unless there is a fix already. I hope this hacker gave AMD notice to develop some protection b4 publishing.
THX reg 4 keeping us in the know!
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.
Isn't there something a little wrong about using some random value in a register as a "password?" Is there any reason this particular value would be expected not to occur in the course of normal operation?
Regardless, this sort of thing is fun to hear about. Like finding a long-hidden easter egg, only potentially useful.
Intel has such mechanisms too. They are even documented in their i386 users manual. If you care to take a look at the full blown technical manual for these cpu's you will find them under the chapter marked 'ICE' or in-circuit emulation. There are registers that let you single step the cpu and trace its internal contents. You can probe the cache memory and more.
Any chip made has test registers that are accessed by performing certain operations. This simply unlocks test mode and allow manipulations that are otherwise not possible.
During ATE test ( the final step before a chip is sold. This is where the entire chip is tested ) they use these special registers to test the built in ram's. This can be done much faster that way as opposed as to having the cpu run the test code itself. ATE test time is expensive. Very expensive. And it is cheaper to spend a couple of square mils on additional test hardware that can bypass normal operation thant o sacrifice test speed.
What is weird is that this is accessible using a software unlock. Normally this is done by pulling a certain pin high or low during the reset cycle ( a condition that does not normally occur at runtime and can be done only on specialised hardware )
I happened to be touring the labs of a now defunct server manufacturer when a bunch of engineers from AMD were on site debugging EFI and saw this in action. I mistakenly assumed at the time they had some sort of ICE installed, but the box was on the bench with the lid off and there was no obvious extra equipment hooked up to it. Cool huh?
I wouldn't assume Intel don't have similar. Their techs always work behind locked doors apparently.
ultimately controls the system. But isn't that what people bought their computers for in the first place ?
So I guess this is bad news for those who supply software and 'protected content' with a different agenda. Personally I don't think it's a good thing for system owners to be kept in the dark concerning what happens on hardware systems they own in law. It will be an advance if this kind of disclosure puts the end to schemes which are inherently insecure because the crypto key is part of the system supplied to the 'untrusted' hardware owner who is the rightful owner of the system. But dealers in such treacherous software and content have no right not to be cracked in the first place, to the extent human rights outweigh copyrights and will be found to do so by courts which decide this to be the case.
Lets remove the scary bits.
Whats that there?
It's a debug tool we use to test chips, pretty common.
But it's password protected!
Yes, that's to stop people using it by accident or being a bunch of dicks and pissing around with it and ultimatly fucking up there machines.
There, Daily Mail headlines removed.
For goodness sake, this isnt a back door that will allow hackers to break security of an AMD based system. This ONLY works if you have your hardware enabled for debugging. I doubt that off the shelf hardware will let you do this and it certainly not a factory default.
The only repercusion is that is if by using the full debugging mode they get a chance to spot some generic vulnerability either in the processor or in the software in the OS. The later I guess they could have done with an Intel anyway or with anyone that has a full blown ICE.
"This ONLY works if you have your hardware enabled for debugging. I doubt that off the shelf hardware will let you do this and it certainly not a factory default."
Isn't this discovery saying all off the shelf AMD CPUs in the last decade does indeed let you do this, and it is simply enabled in software.
This is prime target for rootkits. Not likely that people will get tricked into installing rootkits? Tell that to victims of Sony.
It's a debugger, so what?
Even if some 133t haxor were to use their formidable skillz and plugged in some warez so that they could access my kernal remotely without my knowing about it (maybe even turning on my home computer by pinging my electricity supply while I'm at work to make sure I wouldn't notice!), what would skulduggery would they be able to engage in with this debugger that they couldn't do otherwise?
If they wanted to reverse engineer the CPU, they probably wouldn't need this debugger to do it.
If our AMD man 'Mats' is to be believed, then it was just a debugger; why would those breadcrumbs from the debugging process still be there in the debugger on all factory issued chips?
Be a hell of an insight into the CPU development process if they were, but are they there?
Ehm, it's there to help developers (but also useful for debugging in factory at times). It's just not OFFICIAL. If you have an NDA with AMD for software development, I'm pretty sure it's in that version of the "BIOS developers guide" or whatever the document is called.
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].
Hi! Matsp you're perfectly right on every count.. Thank you, mat !
As the guy who found and publicised that little trick of AMD's trade, I must add I'm mildly amused, and amazed too, at all the nonsense spread by other commentors all over the net. I'll take the opportunity here for debunking a couple of nonsense statements, after presenting excuses for the poor level of my English writing.
Nonsense #1 debunked : No, this feature is not some backdoor for debugging the chip at the factory. Its natural use is for programmers like you and me "debugging" their own programmes (or maybe hacking others' , where and when allowed). It is therefore unfortunate that AMD chose to keep it secret for their own reasons - whatever those reasons were.
Nonsense #2 debunked: No, this feature will not create new security problems (at least as far as I've uncovered it). It is a set of extensions to the usual debugging features of Intel's architecture introduced in the mid-eighties (80386). Instantiating the features correctly requires the processor to be in the most privileged "ring zero" of protection. More scrutiny may be wanted, but at first sight it doesn't look like expanded debug capability will increase the "attack" potential against OSes or Virtual Machines even though those OSes or VMs were unaware of the existence of the features.
Czernobyl (me AT czerno.tk)
Good summary, removes the FUD.
Not the normal El Reg style comment, but very timely just the same.
This feature is possibly slightly useful to people working at the device driver level, but then if you are doing that and have access to the kernel already, do you need this? Probably not. All it really says is that AMD designers future-proofed their own developement and debugging of the CPU internals, so they may be smarter than we thought.
Bu then, as I run water cooled AMD Phenom Black 4 core overclocked CPUs I suppose I already knew that.
Kudos to Czernobyl for his write up.
Mines the one with "ALU Microcode for fun and profit" in the inside pocket.
AMD documents the key in some of their public docs since at least 2005/2006.
Brute Forcing? I suggest you guys just read the coreboot (www.coreboot.org) source code for some of the stuff. The key has been in there since June 2006, being used to change the CPU name reported by CPUID. :-)
Biting the hand that feeds IT © 1998–2019