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

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?

Comments

Do it

[bsDaemon]

Frankly, it would change my buying behavior if they did this. Until then, all things being equal, i'm plenty happy with my new Xeon-based laptop.

Re:Do it

[KiloByte]

I agree with you that this will matter only once AMD actually delivers. But my conclusion is the opposite: instead of buying certain to be backdoored Intel, my next laptop will be a Pinebook, using entirely free software with no firmware blobs, in control of the machine from the moment ROM code loads and jumps to the SPL.

I don't care much about customer's servers, as they don't carry my data -- I do mention the issues but don't force anyone to pander to what I consider reasonable.

On my home primary desktop, though, I use an old Phenom2 x6, from before AMD processors became backdoored. It is adequate for my needs (I don't mess with big packages), although recently I started to do more kernel compiles and indeed the machine feels long in the tooth. Let's see how the brouchacha ends up.

And don't call me too paranoid. I'm nowhere near a juicy target, but I still can upload Debian packages, and source-only/reproducible uploads are not yet mandatory. For example, I recently NMUed dash (aka /bin/sh), my upload will be the one used in Stretch and thus on millions of servers, some of which are juicy targets. Now think if the binary didn't happen to be produced by the source, and had some "extras". Built with non-standard compiler options and/or version to thwart disassemble diffs -- let's take a SVN build of clang from halfway between major releases, that'd kill automated review nicely. If you feel extra vicious, doing some arithmetic on syscall arguments will defeat static analysis. Make your payload's trigger depend on a hash of unobvious characteristics of your target, and perhaps even use that hash in the above syscall arithmetic.

Yeah, it is possible to hide an intentional hole in plain view in the source (the Underhanded C Contest has some ideas how) but that's insanely more work, and if you're not a regular contributor to a project you want to suborn it'd be tricky to submit large enough piece of code to survive review. In comparison, passing a tainted binary is so much easier -- and thus, cost-effective, that at this moment I'd expect a rational attacker to go this way.

Thus, even though I'm a mere unimportant Debian Developer, I am trusted (in the negative sense of the word) with your security, and thus it's my duty to do my best. Yeah, some of Debian buildds and archive machines do use recent Intel CPUs, but they're also far more watched than my private machines and thus it'd be harder to suborn them without being noticed than the dash hack I just described.

Re:Do it

[Dunbal]

Yes especially given the current headlines, AMD has a unique opportunity to make a strategic decision that could significantly impact their market share in the future if they position themselves as "more secure" than proprietary, hackable Intel.

they'd want to, but...

[KiloByte]

Pros: it'd increase security (review), be what some customers want, give AMD an edge against Intel at no monetary cost.
Con: it's against express wishes of US three letter agencies who want their backdoors

So... no.

Re:Is this a why-is-open-source-more-secure thread

[KiloByte]

For some random package, open source is not necessarily more secure (no one bothers to review). Same for even high profile targets that are too big to humanly review (browsers) although available source already gives quite an edge. But the PSP code is really small, and has a horde of researches salivating at the thought of taking a look.

Re: Competition

[Anonymous Coward]

If they open it up, Intel will be the loser.
No one trusts Intel ME.

Re:GPU's

[Kjella]

In the GPU arena, AMD has been pretty active in contributing the the GPU drivers, to the point newer cards can game nicely Linux systems with the in-kernel drivers. Perhaps a similar thought-pattern will apply to other products.

If I remember correctly even there they have some firmware that runs on the GPU that is closed source. It could have been on a ROM/EPROM, but it's loaded by the driver. Truth is, if you don't trust the hardware it doesn't matter. You could have a magic number trigger like

mov ax, 0xDEADBEEF
mov bx, 0xABCD1234
mov cx, 0xC1AC0D35
mov dx, 0xN5AC0D3S
nop

And that would brick it or enable a secret spy mode. The only way you could validate that the CPU only does exactly what it's advertised to do would be to put it under an electron microscope and validate the transistor design. Of course open source is better than closed source, it's harder to hide this shit in hardware. But if you want to put on the tin foil hat there's no reason to trust it either way.

Ideally

[sexconker]

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.

Re:Ideally

[Anonymous Coward]

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'

Re:Ideally

[serviscope_minor]

The only functions of these things (Intel's is called the Management Engine) are backdoors and DRM.

And stopping the CPU from cooking itself. Things like temperature related shutdown are controlled by the main CPU. Naturally, interrupts from that subsystem are infinite priority and unmaskable, not to mention invisible to the OS. They also play merry hell with hard realtime response because you can't stop them, can't prioritise them, they introduce high, unknown latency and there's nothing you can do.

Re:Is this a why-is-open-source-more-secure thread

[KiloByte]

Some of those researchers are paid per paper. Others are sponsored by their companies and/or governments -- those 6500 core-years Google used for SHA1 collision weren't exactly free. Thus, there's a non-negligible number of paid people doing this work.

And no, I don't do security (beyond the "common"-sense).

Re:GPU's

[cfalcon]

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

hackable firmware hurts everyone

[Anonymous Coward]

If AMD embraced open firmware, it would make a huge difference in numerous markets: obviously cloud and web-hosting, but also HPC (my field).

Must be open source to succeed.

[tietokone-olmi]

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.