Beta

×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Hidden Debug Mode Found In AMD Processors

timothy posted more than 3 years ago | from the sooper-seekrit dept.

AMD 154

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!"

cancel ×

154 comments

Sorry! There are no comments related to the filter you selected.

Why... (1, Interesting)

Anonymous Coward | more than 3 years ago | (#34205734)

don't they reveal this to the users?

Security? (4, Interesting)

JSBiff (87824) | more than 3 years ago | (#34205796)

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?

Re:Security? (4, Interesting)

Anonymous Coward | more than 3 years ago | (#34205854)

It is possible that the debug features are for their internal use and they don't quite work as intended. They may be useful as such, but if there are implementation bugs that require cumbersome work-arounds on the software side, it may be that they are waiting for a non-buggy implementation before publically documenting the features.

It is also possible that they don't want to put the resources to documenting and supporting the debug features. After all, AMD is a small company compared to Intel and not that profitable. They even had some layoffs during the worst recession - what if they had to lay off the guys responsible for the debug mode?

Re:Security? (4, Insightful)

TrisexualPuppy (976893) | more than 3 years ago | (#34205916)

It's probably that AMD doesn't want to claim that they ever marketed the feature as such. If they did, it would put Intel up to create and release a debugging interface for their silicon. Then both would be forced into competing to produce a better debugging interface. This drives production costs up for a component that may be used by less than 1/100 of a percent of the users when they should have been putting their efforts elsewhere.

Re:Security? (4, Insightful)

camperdave (969942) | more than 3 years ago | (#34206014)

it would put Intel up to create and release a debugging interface for their silicon.

Maybe Intel already has a debugging interface on their silicon. This AMD interface has remained hidden for who knows how many years, why couldn't the same thing happen with Intel? After all, it's not as if just anyone can reverse engineer a CPU.

Re:Security? (0)

Anonymous Coward | more than 3 years ago | (#34207044)

Reverse engineer a simple CPU? That's so elementary. Now, if you were debugging REALITY.SYS, you would have something to brag about!

Re:Security? (5, Informative)

TheRaven64 (641858) | more than 3 years ago | (#34206134)

Intel has provided debug registers for ages. You can have up to four hardware watchpoints in pretty much any Intel - and AMD - chip. TFA is Slashdotted at the moment, but 'hardware data-aware conditional breakpoints, and direct hardware 'page guard'-style breakpoints' can both be implemented on any chip since the 386.

Re:Security? (5, Informative)

TheRaven64 (641858) | more than 3 years ago | (#34206216)

Okay, the site's still down but I found a cache:

In fact, this is a fairly small incremental improvement over the existing hardware debugging support in x86 chips. It provides some extra control codes allowing the address in DR0 (one of the four registers i386 provides for hardware watchpoints) to do some slightly more clever things. For example, a watchpoint can be triggered on a partial match, rather than an exact match, to the address - this is really nice because it lets you put a watchpoint on the whole of any data structure that fits within a page. With the i386 watchpoints, you can only watch a single word with each register (4 words in total), while this means you can watch anything smaller than a page (and you can watch things bigger than a page by marking the page as no access, trapping the access, then unprotecting, single-stepping through the load / store, and continuing the process, which is how you implement watchpoints when you run out of debug registers).

Re:Security? (0)

Anonymous Coward | more than 3 years ago | (#34206738)

It is also possible that they don't want to put the resources to documenting and supporting the debug features.

That's it. The customers aren't paying for the debug features, so AMD thinks they shouldn't get the features, even if they are there already.

The high-end UPS that my company uses has pricing for different capacities. If you upgrade to a higher capacity, they don't send you a new UPS, they send you a chip or something that un-cripples it. I'm not sure if I agree with the business model or not.

Re:Security? (3, Interesting)

anotheryak (1823894) | more than 3 years ago | (#34206860)

Exactly, it's probably a bit of a kludge, and making it into a stable, documented, supported feature is going to be expensive with a lot of support and a small user base.

I have modes like this in some of my own products, and sometimes I'm leery of even having some other people on my own team have access to the debug modes, because of the potential for disaster and a WHOLE lot of handholding from me.

It's not worth the time it would take for me to set it up for broader use, and if I did, they would break things and then come running to me.

Re:Security? (4, Insightful)

LordNimon (85072) | more than 3 years ago | (#34207228)

It is possible that the debug features are for their internal use and they don't quite work as intended.

Ding ding ding ding ... we have a winner!

I work for a processor design company. If this feature is kept secret, it's because the company does not want to put in the resources to make sure it works completely on every chip. It probably uses lots of hacks and violates the architecture in some obscure way. AMD does not want customers depending on this feature and then insisting that it works for future design wins.

Re:Security? (3, Insightful)

slashqwerty (1099091) | more than 3 years ago | (#34205882)

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?

If there is some way to enable privileged instructions without using a privileged instruction it would completely circumvent operating system security.

Perhaps the slashdotted site answers this but I have to wonder why not just have a separate opcode to turn the debugging on?

Re:Security? (3, Informative)

makomk (752139) | more than 3 years ago | (#34206236)

Perhaps the slashdotted site answers this but I have to wonder why not just have a separate opcode to turn the debugging on?

Because there's already a whole bunch of privileged MSRs that normal user code mustn't have access to - many of which are undocumented and processor-specific - so adding a few more is no big deal. Adding new opcodes, on the other hand, requires more work and risks them clashing with Intel's opcode choices at a later date.

Re:Security? (5, Insightful)

fuzzyfuzzyfungus (1223518) | more than 3 years ago | (#34205886)

Any CPU debug mode worthy of the name should be able to violate OS security six ways from Sunday, and silently at that, without any difficulty. By the same token, though, any CPU debug mode worthy of shipping in commercial silicon really ough to be possible for the firmware and/or kernel to lock for the duration of operation. If userspace can kick it off, a brave and exciting new world of AMD-specific malware is about to begin...

Re:Security? (1)

Joe U (443617) | more than 3 years ago | (#34205920)

Wasn't this the whole reason for microcode updates? To turn off or fix broken features.

Also, if it's triggered in userspace, the OS can block it.

Re:Security? (2, Insightful)

Anonymous Coward | more than 3 years ago | (#34205986)

Also, if it's triggered in userspace, the OS can block it.

Not if your OS is rooted. Or root-kitted. Or both.

Re:Security? (2, Insightful)

Joe U (443617) | more than 3 years ago | (#34206288)

Also, if it's triggered in userspace, the OS can block it.

Not if your OS is rooted. Or root-kitted. Or both.

That's already game over. If you own the OS, why would flipping the processor into a new mode help?
  You already own the security system.

Re:Security? (4, Interesting)

TheLink (130905) | more than 3 years ago | (#34206454)

Say you own the OS but it is in a virtual machine.

If flipping the processor into a new mode allows you to get out of the virtual machine and pwn the Host too, then yes it makes a difference.

Re:Security? (2, Interesting)

Anonymous Coward | more than 3 years ago | (#34207240)

If an OS running on real hardware can block this call coming from user-mode then a hypervisor can block it coming from a VM. And if it can't be blocked you're p0wned either way. A virtual machine makes no difference.

Re:Security? (0)

Anonymous Coward | more than 3 years ago | (#34207564)

Not that I'm that knowledgeable about virtualization software, but I can't imagine that they would run priviledged code in the virtual machine as priviledged code on the host CPU, so it doesn't matter anyways.

Re:Security? (-1, Redundant)

Anonymous Coward | more than 3 years ago | (#34206668)

If the OS is already rooted then there's no need for hardware-based privilege escalation.

Re:Security? (2, Informative)

Anonymous Coward | more than 3 years ago | (#34206002)

if it's triggered in userspace, the OS can block it.

Not necessarily. Memory access can be blocked because the MMU controls what and where an application can write, transferring control to known code (the OS) on violations. Interrupts can be blocked because invoking them gives control to the OS. Priviliged instructions can be blocked because non-ring0 execution gives control to the OS.

The OS can't choose to block for example the "xor" instructions in any reasonable way. It's possible by basically single-stepping through instructions at 100x the overhead, but it's not feasible.

Re:Security? (2, Informative)

jimicus (737525) | more than 3 years ago | (#34206102)

IIRC, microcode updates are typically packaged as part of BIOS updates.

Tell me, how many PCs - as a percentage of those sold - get their BIOS regularly updated?

Re:Security? (2, Informative)

tibit (1762298) | more than 3 years ago | (#34206416)

AFAIK they are packaged with every major linux distro out there, and I can't but presume that Windows ships with microcode patches as well.

Re:Security? (3, Insightful)

wbo (1172247) | more than 3 years ago | (#34207022)

AFAIK they are packaged with every major linux distro out there, and I can't but presume that Windows ships with microcode patches as well.

Microcode updates for Windows machines are distributed through Microsoft Update and are downloaded and installed automatically if automatic updates is enabled (and it is enabled by default). No BIOS update required.

An example of such an update can be found by looking at Microsoft KB936357 [microsoft.com]

Re:Security? (1)

joeyblades (785896) | more than 3 years ago | (#34206598)

Any CPU debug mode worthy of the name should be able to violate OS security six ways from Sunday...

Any security model worthy of the name would be agnostic to whether the CPU was in user mode or debug mode. While there is always the risk of a bug or a security hole, I can assure you that anything that goes into the chip goes in under the scrutiny of the security model. I know of many instances where some debug or test feature was not implemented because there was some potential threat to the security model.

Re:Security? (1, Interesting)

Anonymous Coward | more than 3 years ago | (#34205904)

Yeah, security of DRM or TPM is probably easier to compromise (instead of taking several months to break a new DRM system it would take days since reverse engineering can be done much faster)... Which also is an obvious reason they would want to hide this feature to avoid pressure from certain groups.

Re:Security? (1)

Jurily (900488) | more than 3 years ago | (#34205908)

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?

Exactly my thoughts as well. Perhaps if these features were documented, and compilers and kernels were written with these features in mind, they would be insanely helpful. This way, however, it's just a back door wide open.

Re:Security? (1)

xtal (49134) | more than 3 years ago | (#34206256)


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?

Depending on how it is implemented, yes. Usually these operating modes require specific timing or hardware ports that are wired in silicon.

If they've got software overrides, possible timing chase conditions to trick timing, then yes, oh snap indeed.

Re:Security? (1)

Shark (78448) | more than 3 years ago | (#34206346)

I guess this [slashdot.org] research is going to come in handy for some people if you're right. I'm hoping you're wrong though, the number of ways such an exploit could go wrong makes my head spin.

Re:Security? (2, Informative)

Anonymous Coward | more than 3 years ago | (#34207032)

I used to work for a processor emulator tools company called Applied Microsystems Corp, Redmond WA. now defunct.
Up thru processors type 68040 emulations tools could be mounted external to the processor chip and performed the functions mentioned ( hardware breakpoints, memory maps, all register shadowing, soft and hard breakpoints, etc, all the things that you need to perform basic computer system development. As the complexity of the systems increased beyong those early 8/16/32 bit cpu, all those hardware functions became embedded into the processor itself and are accesed by usually an I2c serial link. Emulation tools went from hardware and software complex and external to the system to hardware simple internal and software complex and external. The bottom dropped out of the eumlator tools market ( from 50k$ to 5K$ ) and that whole industry went away and got smaller and fewer in number. But the hardware tools remain inside the cpu's now, accessible by hardware licensed developers in NDA contracts. But for a few years even a few technicians had an understanding of the fine details of cpu internals. Now all that is buried again.

Re:Security? (1)

currently_awake (1248758) | more than 3 years ago | (#34207416)

NSA key? Generally speaking, if a company spends money on something it expects a return. Putting those "debug" features into silicon costs money so why don't they advertise them? I only see three likely reasons: security (can't be secured), doesn't work (oops!), government backdoor.

Re:Why... (0, Redundant)

cindyann (1916572) | more than 3 years ago | (#34206042)

They did.

It's all documented there in the silicon.

It's not their fault you didn't read it.

Or that you don't have the tools necessary to read it.

Or that you're not intelligent enough to read it.

But once they document it in, e.g. human readable form, then they might be afraid that they'd have to support it in this and all future generations of their chips. Perhaps they don't want to be constrained to always supporting those particular features going forward.

Re:Why... (0, Redundant)

Waffle Iron (339739) | more than 3 years ago | (#34207396)

don't they reveal this to the users?

Probably because then they'd have to fully document the features and test them thoroughly on each new chip, which would likely cost them quite a bit more than developing the features in the first place.

They would also be saddled with supporting backwards compatibility in future chips, since it becomes hard to remove publicly-accessible features in a CPU once they've been added.

Yeah but ... (1)

Thing I am (761900) | more than 3 years ago | (#34205742)

can you harden the processors from the Slashdot effect?

Just a matter of time... (5, Interesting)

TrisexualPuppy (976893) | more than 3 years ago | (#34205754)

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.

Re:Just a matter of time... (5, Informative)

TrisexualPuppy (976893) | more than 3 years ago | (#34205826)

By the way, here's a guy who does this in his spare time [bunniestudios.com] . He may not have the $10+ million budget that the big boys have, but it should give you a little context as to what really happens in industry.

(As the original article was instantly slashdotted, I can only guess that the AMD exploit was found through software avenues.)

MOD PARENT UP!! (-1, Offtopic)

Anonymous Coward | more than 3 years ago | (#34205828)

This is so cool!

Oops, slashdotted! (4, Funny)

ThreeGigs (239452) | more than 3 years ago | (#34205756)

Apparently the debugging process doesn't help to combat the effects of a thorough slashdotting.

Re:Oops, slashdotted! (2, Interesting)

Danathar (267989) | more than 3 years ago | (#34205784)

yea, why stories continue to be posted with direct links instead of using things like coral cache is beyond me. If you KNOW the site you are going to link to can't handle a slashdot load then DON'T LINK DIRECTLY TO IT.

Of course this does not include sadistic evil people who enjoy watching websites crash and burn (probably a sizable but not large percentage portion of the slashdot community)

Re:Oops, slashdotted! (1)

fiendy (931228) | more than 3 years ago | (#34207116)

Ah yes, I've seen this before...the typical way this is done is to hide the article behind at least three blog posts, thereby decreasing the chance that anyone will actually RTFA.
I believe that's how it usually goes right?

Re:Oops, slashdotted! (1)

autocracy (192714) | more than 3 years ago | (#34206510)

No kidding? Running debug mode doesn't speed things up?

I'm so patenting this secret to making Java speedy... then I'll own Oracle!

Hidden? (0, Troll)

Janek Kozicki (722688) | more than 3 years ago | (#34205774)

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.

Re:Hidden? (4, Insightful)

neokushan (932374) | more than 3 years ago | (#34206008)

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.

Re:Hidden? (2, Insightful)

icebraining (1313345) | more than 3 years ago | (#34206074)

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.

Re:Hidden? (0)

Anonymous Coward | more than 3 years ago | (#34206384)

Tested by Kojak?

Re:Hidden? (0)

Chelloveck (14643) | more than 3 years ago | (#34206392)

My question is, is this actually hidden? Stuff like this is usually in the data sheets. So, does anyone have access to the actual processor data sheets? I didn't find them on AMD's site, just stubs containing the first few pages.

Re:Hidden? (0)

Anonymous Coward | more than 3 years ago | (#34206502)

I like AMD as well and try to support them. I do not expect them to document *EVERY* possible feature of their cpu that is not advertised as a feature. They likely have other things that are more important to them at the moment, and this is likely fairly low on the list of priorities.

Just wait till the Gubmint finds out (-1, Flamebait)

ickleberry (864871) | more than 3 years ago | (#34205782)

And they'll mandate some sort of encryption to gain access lest anyone is able to use it for cracking DRM schemes.

Even now AMD engineers are busy at work making these features harder to get to lest Microsoft threatens to stop supporting AMD processors.

Coral Cache link (0)

Danathar (267989) | more than 3 years ago | (#34205792)

http://www.woodmann.com.nyud.net/collaborative/knowledge/index.php/Super-secret_debug_capabilities_of_AMD_processors_ [nyud.net] !

may not work until SOMEBODY uses the coral cache and is able to see the site (and thus cache it for the first time)

Re:Coral Cache link (2, Informative)

Trevelyan (535381) | more than 3 years ago | (#34206018)

Won't work at all, because you lost the '!' on the end..

Try this [nyud.net]

Re:Coral Cache link (1)

burisch_research (1095299) | more than 3 years ago | (#34206776)

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 /..

The ultimate security disaster? (4, Insightful)

pyalot (1197273) | more than 3 years ago | (#34205808)

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

Re:The ultimate security disaster? (1)

HelloKitty2 (1585373) | more than 3 years ago | (#34205852)

Haha, that would have been hillarious. All that security and someone compromising it with a simple 6letter pass :D

Re:The ultimate security disaster? (0)

Anonymous Coward | more than 3 years ago | (#34205866)

Are you surprised? Do you believe that security services aren't provided with the combinations for access?

The argument that OSS is as secure as the many eyes which (usually don't) audit its source code is useless unless the system is fully open and locally built down to the level of understanding the physics.

Re:The ultimate security disaster? (2, Interesting)

pyalot (1197273) | more than 3 years ago | (#34205938)

It's not that I'm surprised. But you need to recall that AMD chips a goodly chunk of data/hosting-center cores, which run many clients on the same machine... AMD will need a very good indemnification clause to wind their way out of that dammage responsibility.

Re:The ultimate security disaster? (5, Informative)

Eil (82413) | more than 3 years ago | (#34206054)

Not a security hole. This debug mode is not some kind of eleet hax0r backdoor. It's for debugging the processor and microcode.

It's the OS responsibility to ensure that normal applications can't simply do whatever they like directly to the hardware, including the CPU.

Re:The ultimate security disaster? (2, Insightful)

Smallpond (221300) | more than 3 years ago | (#34206056)

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

Any program that can read and write to any processor register already has complete access to everything on your computer. The reason this is secret is not to protect your data, its to protect AMD's secrets.

Re:The ultimate security disaster? (1, Interesting)

pyalot (1197273) | more than 3 years ago | (#34206104)

Just hypothethically, given the information we have from the summary, what's the worst case scenario?

- The debugmode is worthy of its name, i.e. can bypass any ring and OS restriction
- It cannot be turned on or off in the bios or with a pin, since it is undocumented
- It is on by default
- The bit combination to set resides in usual working registers and can be triggered by usual computation by native code or in any bytecode interpreter (javascript, java etc.) of your choice when carefully targeting the bytecode interpreter

google cache of the article (3, Informative)

avgapon (1851536) | more than 3 years ago | (#34206126)

hardware watch conditional watch (0, Redundant)

avgapon (1851536) | more than 3 years ago | (#34206146)

It seems that the discovered functionality is about extending standard hardware watch feature with ability to match actual data being accessed, not only address.

Re:The ultimate security disaster? (1)

Seth Kriticos (1227934) | more than 3 years ago | (#34207140)

No, TFA said (before it went down) that some registers have to be filled with defined values through hardware means to enter debug mode. In short, you won't stumble into it. And neither will any harmful software.

Czernobyl == Polish Hacker? (1)

Mastadex (576985) | more than 3 years ago | (#34205814)

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.

Re:Czernobyl == Polish Hacker? (0)

Anonymous Coward | more than 3 years ago | (#34205858)

Starting?

Ever heard of the bomba?

The poles were reverse engineering stuff before pretty much everybody else.

Re:Czernobyl == Polish Hacker? (-1, Offtopic)

takowl (905807) | more than 3 years ago | (#34205978)

Chernobyl is in the Ukraine, not Poland.

Re:Czernobyl == Polish Hacker? (0)

Anonymous Coward | more than 3 years ago | (#34206062)

Nobody suggested otherwise.

Re:Czernobyl == Polish Hacker? (0, Offtopic)

devjoe (88696) | more than 3 years ago | (#34206072)

Chernobyl is in the Ukraine, not Poland.

Whoosh! Sure, the city is, but in this story we are talking about a hacker who lives in Poland who named himself after the infamous Ukraine nuclear disaster site.

Re:Czernobyl == Polish Hacker? (0, Offtopic)

Anonymous Coward | more than 3 years ago | (#34206094)

But spelling the name with a z (Czernobyl) is Polish.

Re:Czernobyl == Polish Hacker? (0, Offtopic)

Marcx77 (1193559) | more than 3 years ago | (#34206274)

Well, it's not as if spelling it with an 'h' is Ukrainian....

Re:Czernobyl == Polish Hacker? (0)

Anonymous Coward | more than 3 years ago | (#34206292)

No, Polish spelling is Czarnobyl

They did years ago in 2008's "TopCoder"... apk (0)

Anonymous Coward | more than 3 years ago | (#34206582)

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 [wsj.com]

(So, they've already "been there, & done that", and pretty handily)

APK

P.S.=> Polish here myself, by the by... apk

Re:Czernobyl == Polish Hacker? (0)

Anonymous Coward | more than 3 years ago | (#34207334)

Starting? Learn2history.

http://en.wikipedia.org/wiki/Jacek_Karpinski
http://en.wikipedia.org/wiki/K-202

One of my professors knew the guy in person.

(yeah I'm polish.)

hidden data-aware conditional breakpoints (4, Funny)

digitaldc (879047) | more than 3 years ago | (#34205818)

Hidden for a reason? Do they not want Nvidia to see this?

So it's a software JTAG (5, Interesting)

leptechie (1937384) | more than 3 years ago | (#34205822)

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.

Re:So it's a software JTAG (1)

doogledog (1758670) | more than 3 years ago | (#34205950)

I'm just guessing, as the site is still inaccessible, but it sounds like this is a set of debug functionality beyond what you'd get with the normal debug registers or with a JTAG interface. AFAIK modern desktop/server processors still have JTAG interfaces (not just SoC, embedded type processors). Sure JTAG interfaces are often 'hidden' as you say... maybe there's a footprint there but you have to solder on some flying leads or a connector.. but without knowing about these new registers you still wouldn't be able to use these debug features over JTAG.

Re:So it's a bit like a software JTAG, but not... (1)

leptechie (1937384) | more than 3 years ago | (#34206000)

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.

Re:So it's a bit like a software JTAG, but not... (1)

doogledog (1758670) | more than 3 years ago | (#34206340)

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.

Re:So it's a software JTAG (1, Interesting)

Anonymous Coward | more than 3 years ago | (#34206038)

It's not the same thing. Virtually every microcontroller has JTAG support and nobody would be surprised to find a JTAG interface in an embedded device. It would be very well documented in the datasheets. It's no big deal to find an unpopulated serial or JTAG header in a production device. These aren't manufacturer secrets -- they are well-known debugging interfaces provided for the benefit of the device developer.

AMD's proprietary debugging features are a different story -- features not intended for the end-user to have access to and which can have a serious impact on privacy and security. This has nothing to do with extracting performance and everything to do with reverse engineering software.

Frankly it sounds like you've been "around" these sorts of things but not had much first-hand experience working with them. Imagining a device has a hardware debugger and actually finding an undocumented one are two very different things.

Re:So it's a software JTAG (0)

Anonymous Coward | more than 3 years ago | (#34206414)

Why is this flamebait? He (or she) is right!

Some extra info, whilst the site is 'dotted... (1, Informative)

Anonymous Coward | more than 3 years ago | (#34205880)

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

Grab your martini-wodka and get to work (0, Offtopic)

b4dc0d3r (1268512) | more than 3 years ago | (#34205926)

+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.

Re:Grab your martini-wodka and get to work (0)

Anonymous Coward | more than 3 years ago | (#34205966)

After adding the first 4 ingredients, I experienced a buffer overflow. Did I just get hacked?

Re:Grab your martini-wodka and get to work (1, Offtopic)

inode_buddha (576844) | more than 3 years ago | (#34205996)

+0rc was one of the better ones, also. Very outdated nowdays but I still have a bunch of his tutorials around here somewhere...

Re:Grab your martini-wodka and get to work (0, Offtopic)

lxs (131946) | more than 3 years ago | (#34206632)

Offtopic? That's what you get when mentioning sites that closed when your average mod was a mere glint in the milkman's eye.

Extensions for gcc/gdb (1)

NtwoO (517588) | more than 3 years ago | (#34205958)

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.

long longed for by (0)

Anonymous Coward | more than 3 years ago | (#34205992)

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 bet (0, Redundant)

VincenzoRomano (881055) | more than 3 years ago | (#34206016)

Someone will find something similar in Intel chips as well.

Just an extension of existing debug facilities (5, Informative)

Menacer (222952) | more than 3 years ago | (#34206176)

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.

Re:Just an extension of existing debug facilities (1)

Joce640k (829181) | more than 3 years ago | (#34206310)

Surely a good debugger can already do that...ie. When it hits a breakpoint it checks what value is being written and continues if it's not right.

The fact that this is 'hardware' doesn't seem like much of a win to me.

Re:Just an extension of existing debug facilities (5, Informative)

Menacer (222952) | more than 3 years ago | (#34206406)

Sure, but it's much faster to do it in hardware. This is the whole reason data watchpoints exist (See, for instance, the paper "Some Requirements for Architectural Support of Software Debugging" by Mark Scoctt Johnson from ASPLOS-I), as you could technically have your debugger put address & data checks around every memory access, but that leads to completely unacceptable overheads. It's faster to let the hardware check the addresses in parallel with regular execution and take a fault only if you touch the watchpoint.

Similarly, if the hardware will check the value before taking a debug interrupt to the kernel and subsequently signaling/scheduling of the debugger, it will be much, much faster than performing all that and then have the debugger check the address & throw this particular interrupt away before continuing execution. That constant interrupt cycle can cause 10,000x or more slowdowns if you're constantly accessing a value & taking bad watchpoints on it.

Re:Just an extension of existing debug facilities (3, Insightful)

deKernel (65640) | more than 3 years ago | (#34206604)

If you are an application developers, I would agree with you. Any decent debugger should allow you to set a conditional breakpoint, but I am not sure if you can say that for kernel debuggers which are very different animals typically.

Re:Just an extension of existing debug facilities (0)

Anonymous Coward | more than 3 years ago | (#34206606)

Depends what you're working on. If the match fires hundreds/thousands of times per second, having it checked all the way back in software can be very costly and slow.

Re:Just an extension of existing debug facilities (5, Informative)

Menacer (222952) | more than 3 years ago | (#34206336)

Oh, and the summary's description, "hardware data-aware conditional breakpoints, and direct hardware 'page guard'-style breakpoints", matches up with the line I copied & pasted from the forum post. I previously described the "hardware data-aware conditional breakpoints"where you can make hardware take a fault if an address of a memory operation is matched && the value of the memory operation matches. Looking through my notes, embedded Power ISA (Book III-E) processors also let you set value-dependent watchpoints using the Data Address Compare (DAC) Registers. I'm not sure about other ISAs.

The second party of the summary's statement refers to to 'page guard'-style breakpoints. This is referenced by Czernobyl's "masking of any or all of 12 low address bits". Again, this is a very interesting extension of the x86 debug registesr, which only allow debug watchpoints of size 1, 2, 4, or 8 bytes (and the latter only in certain microarchitectures & modes) However, by masking out the low 1--12 bits of the address into don't-cares, it's possible to set watchpoints anywhere from 1-4096 bytes, limited to powers-of-two and size-alignment. This is cool from an x86 standpoint, but ARM, MIPS, and Itanium (off the top of my head) already do this.

Suffice it to say, the stuff that Czernobyl found is very cool in relation to x86, especially if these facilities were officially released to the public at any point in the future. However, it's very unlikely to cause any kind of AMD-only viruses or other scary security concerns. These features exist on other ISAs without any kind of world-shattering problems. :)

I wonder ... (-1, Troll)

Anonymous Coward | more than 3 years ago | (#34206182)

what other tricks might be hidden in chips..kill switch perhaps

The site got SlashDotted!!! (0, Redundant)

savvysteve (1915898) | more than 3 years ago | (#34206232)

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.

"long longed for" (0)

Anonymous Coward | more than 3 years ago | (#34206544)

"...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.

Hardware easter eggs (0, Offtopic)

antifoidulus (807088) | more than 3 years ago | (#34206680)

Turns out they implemented an entire flight simulator in hardware :P

NSA? (0, Flamebait)

NapalmV (1934294) | more than 3 years ago | (#34206846)

debug
>NSA
NSA mode is ON
NSA>load spyware
Spyware loaded
NSA>exit
Affirmative
>
Load More Comments
Slashdot Login

Need an Account?

Forgot your password?
or Connect with...

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>