Slashdot Mirror

← Back to Stories (view on slashdot.org)

Message For AMD: Open PSP Will Improve Security, Hinder Intel

Posted by BeauHD on from the question-and-answer dept.

futuristicrabbit writes: AMD has faced calls from Edward Snowden, Libreboot and the Reddit community to release the source code to the AMD Secure Processor (PSP), a network-capable co-processor which some believe has the capacity to act as a backdoor. Opening the PSP would not only have security benefits, but would provide AMD with a competitive advantage against rival chipmaker Intel. Lisa Su, the CEO of AMD, is reportedly seriously considering the change, and the community is working hard to make sure she makes the right decision. In an AMD AMA post via Reddit, user 1n5aN1aC provided several arguments for why the company should release the PSP source code to the Coreboot / Libreboot project (or publicly). The arguments center around security, economic incentives, advertising, brand perception, and mindshare. AMD replied: "Thanks for the inquiry. Currently we do not have plans to release source code but you make a good argument for reasons to do so. We will evaluate and find a way to work with security vendors and the community to everyone's benefit." The product manager for AMD, AMD_james, continued in response to a follow-up comment that claims AMD is "not considering it all but only want to appease the potential buyers." AMD_james replied: "Thanks for the feedback. Please believe me that this has CEO level attention and AMD is investigating the steps and resources necessary to support this. It is not the work of a minute, so please bear with us as we define what we can do." What are your arguments for (or against) the idea of AMD releasing the source code to the AMD Secure Processor?

4 of 52 comments (clear)

  1. Ideally by sexconker · · Score: 4, Insightful

    Ideally the thing wouldn't exist.

    The only functions of these things (Intel's is called the Management Engine) are backdoors and DRM.
    At the high end enterprise level they can be used for remote configuration and asset tracking, but:

    They don't prevent theft. Despite bold claims, they don't actually result in recovering stolen shit either. I'm sure they have a handful of cases to point to, but recovery is rare. If you care about security you're using physical locks to keep things from walking away and encryption for when someone is determined.

    No one remotely configures workstations at a low level. You buy them, image them, and hand them off. BIOS updates? Are you kidding me? For servers, various proprietary solutions exist built on top of open standards. Remote configuration is a big deal here, but we don't need an embedded, all-powerful black box to do it. The dumbest, cheapest (free) IPMI implementation can handle getting power status, rebooting, and piping BIOS over serial (and serial over LAN). And it can be turned the fuck off.

    But AMD won't be removing it, so they could at least allow binary blobs to be loaded which disable functionality. (Or give us a config option or jumper to do the same.)

    Asking them to open source the whole damn thing and hand over signing keys is asking for the moon. It would be great, sure. But I'd settle for the much more reasonable "disable to a fair degree of certainty" option.

    1. Re:Ideally by Anonymous Coward · · Score: 2, Insightful

      But you're still trusting what it's doing at that point. What you argue for changes nothing as far as security is concerned. We can take their word for it that's safe, just as easily as we could take their word that it's 'off'

  2. Re:GPU's by cfalcon · · Score: 3, Insightful

    > mov ax, 0xDEADBEEF

    Here's the thing: not only might that be detectable (low odds, but the company is DONE, full stop), but if you're MOVing shit to my AX register, you already own me. Or ANY opcode at all. If I'm running your code straight, you obviously have everything or almost everything. If you're getting me through some javascript bullshit where it hopefully runs the opcode, your fishing, and I have mitigations.

    The problem with an entire suite of encrypted and signed software running at ring minus 3 is that there's no limit to the functionality you could embed, and since that software has raw access to at least some of the networking, you may have any number of ways to get in.

    So this isn't some academic thing: the existence of Intel's ME and AMD's PSP is a real risk. The idea that the chip may have magic numbers of some secret tap pattern is way less concerning, given that you can connect to a network without just running some guy's opcodes.

  3. Must be open source to succeed. by tietokone-olmi · · Score: 4, Insightful

    As a security product becomes widely used, even close to ubiquitous, its value to an attacker increases to the point where the NSAs and CIAs of the world will cut the damn thing open with a nano-spoon and read its doubly-secret ROMs with a scanning electron microscope. If the product is closed-source, we only know that the product will eventually be backdoored or defeated by an adversary; and implicitly that it may already have been -- there's no security advantage. If the product is open source, we can additionally review it to determine whether there are backdoors, and gain from others doing so (even if just for props).

    But besides being open source, the security firmware should ideally be Free Software as well, and replaceable by the user. Otherwise we can't know what's truly running on there.