Slashdot Mirror

← Back to Stories (view on slashdot.org)

Hidden Debug Mode Found In AMD Processors

Posted by timothy on from the sooper-seekrit dept.

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

14 of 154 comments (clear)

  1. Why... by Anonymous Coward · · Score: 1, Interesting

    don't they reveal this to the users?

  2. Just a matter of time... by TrisexualPuppy · · Score: 5, Interesting

    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.

  3. Re:Oops, slashdotted! by Danathar · · Score: 2, Interesting

    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)

  4. Security? by JSBiff · · Score: 4, Interesting

    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?

    1. Re:Security? by Anonymous Coward · · Score: 4, Interesting

      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?

    2. Re:Security? by Anonymous Coward · · Score: 1, Interesting

      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.

    3. Re:Security? by TheLink · · Score: 4, Interesting

      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.

      --
    4. Re:Security? by anotheryak · · Score: 3, Interesting

      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.

    5. Re:Security? by Anonymous Coward · · Score: 2, Interesting

      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.

  5. So it's a software JTAG by leptechie · · Score: 5, Interesting

    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.

    1. Re:So it's a software JTAG by Anonymous Coward · · Score: 1, Interesting

      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.

  6. Re:The ultimate security disaster? by pyalot · · Score: 2, Interesting

    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.

    --
    Experiments and other stuff
  7. Re:The ultimate security disaster? by pyalot · · Score: 1, Interesting

    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

    --
    Experiments and other stuff
  8. Re:google cache of the article by eulernet · · Score: 2, Interesting

    And the documentation about the new opcode is probably this one:

    http://cbid.softnology.biz/html/undocmsrs.html