3 posts • joined 16 Nov 2010
What's this for???
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].