Message For AMD: Open PSP Will Improve Security, Hinder Intel 52
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?
GPU's (Score:1)
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.
Re:GPU's (Score:4, Interesting)
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.
Re:GPU's (Score:4, 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.
Re: (Score:2)
Oh ya, also that would need to be at least eax, ebx, ecx, edx :P
Do it (Score:3)
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 (Score:2)
Mine too, probably. I've gotten interested in Qubes, and I can see where having the security/management firmware for the processor open and auditable would be a good fit for increasing overall system varefiability, reducing the need for trust.
Re:Do it (Score:4, Interesting)
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.
How practical is Winelib on ARM laptops? (Score:2)
instead of buying certain to be backdoored Intel, my next laptop will be a Pinebook, using entirely free software with no firmware blobs
Say I wanted to switch from my current compact laptop, a Dell Inspiron mini 1012 with an Intel Atom N450 CPU, to a Pinebook. My current workflow includes applications that are made for Win32 API and distributed as free software, such as FCEUX (debugging version), FamiTracker, and Modplug Tracker. (A port of FCEUX to SDL exists, but unlike the Win32 version, the SDL version lacks a debugger.) Currently, I run them acceptably in Wine. How easy is it to, say, recompile them to use Winelib for the Pinebook's AR
Re: (Score:2)
instead of buying certain to be backdoored Intel, my next laptop will be a Pinebook, using entirely free software with no firmware blobs,
So what percentage of the functionality do you have to give up? I know that includes 3d acceleration, all you get is a dumb framebuffer. What other parts of the SoC has Allwinner not contributed open driver source for? I have a PineA64+ and last I checked there were several things not working correctly without blobs.
Re: (Score:3)
Re: (Score:2)
this, do it and its done for me
Intel backdoor almost impossible to decode (Score:1)
Intel used custom compression and multiple instruction sets (ARC/ARCompact/SPARC V8/ARM) for their backdoor to make reverse engineering extremely difficult.
The Trouble With Intel's Management Engine [hackaday.com]
To break the Management Engine, though, this code will have to be reverse engineered, and figuring out the custom compression scheme that's used in the firmware remains an unsolved problem.
But unsolved doesn't mean that people aren't working on it. There are efforts to break the ME's Huffman algorithm. Of course, deciphering the code we have would lead to another road block: there is still the code on the inaccessible on-chip ROM. Nothing short of industrial espionage or decapping the chip and looking at the silicon will allow anyone to read the ROM code. While researchers do have some idea what this code does by inferring the functions, there is no way to read and audit it. So the ME remains a black box for now.
There are many researchers trying to unlock the secrets of Intel's Management Engine, and for good reason: it's a microcontroller that has direct access to everything in a computer. Every computer with an Intel chip made in the last few years has one, and if you're looking for the perfect vector for an attack, you won't find anything better than the ME. It is the scariest thing in your computer, and this fear is compounded by our ignorance: no one knows what the ME can actually do. And without being able to audit the code running on the ME, no one knows exactly what will happen when it is broken open.
The first person to find an exploit for Intel's Management Engine will become one of the greatest security researchers of the decade. Until that happens, we're all left in the dark, wondering what that exploit will be.
they'd want to, but... (Score:4, Interesting)
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: (Score:2)
Con: it's against express wishes of US three letter agencies who want their backdoors
The real con depends upon:
For ever iota of "hard" above "automatic" there will be more people who will never bother doing either, and will never bother installing any updates. For those people, you've made it easier for bad guys to hack this processor because you've given them the code to look at and find exploits, which they would otherwise have to
Re: (Score:2)
You're missing the point. Sure, the group that would actually run an open version is small. But this would grant assurance that there isn't a back door. There's never a guarantee about a bug that grants access in some manner, but if the PSP was open source, or even if there was just an open source version you COULD install (with or without remote management, leaving the closed source one as the default), everyone would have assurance that the AMD chips are not backdoored at factory, on purpose. The odds
Is this a why-is-open-source-more-secure thread? (Score:2)
Is the premise that the C-levels at AMD are going to read /. to discover whether open source security code is safer than closed source security code? Some of us bill by the hour for regurgitating established factual non-opinion-based security information. Hell, some of us are even salaried to do it. What's in it for us?
Re:Is this a why-is-open-source-more-secure thread (Score:5, Interesting)
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: (Score:2)
Good stuff, KB, but you did start chasing the carrot! If I wind you up by disagreeing, will you do more security consulting for free?
Re: (Score:3)
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).
Competition (Score:2)
Given the market conditions -processor companies depending on large payouts from 3 letter agencies for backdoors to be able to create chips at a cost that will sell- AMD does not have a choice. If it releases and loses its govt subsidies , Intel will eat it alive.
Re: Competition (Score:2, Interesting)
If they open it up, Intel will be the loser.
No one trusts Intel ME.
Re: (Score:2)
I'd prefer it to be open. I'd argue for that, pay for it, vote with my wallet, etc.
If they open it up, Intel will be the loser.
No one trusts Intel ME.
But does that matter? They have an effective monopoly (or duopoly) in the desktop and server space.
If they open it up, assuming no other changes, companies are still going to buy Intel by a large margin. Most people will continue to buy Intel, even if they are aware of the ME risk. You and I are likely to still buy it, cause when you get a great deal on a little NUC for the living room, we get it.
Maybe you won't cave, but ple
Re: (Score:2)
Actually, opening up the PSP could mean that someone like Apple take it on. Large companies use the PSP and TPM modules as verification chains and cert sources for remote access.
If the PSP is open sourced, someone the size of Google might put pressure on someone like Apple to change to AMD. That would be a big change in the landscape.
At the very least we might get a model of laptop to compete with Apple (XPS 15 variant perhaps?) out of Dell with this built in.
That'd be a good start for us, and look, Intel m
Play Station Portable? (Score:2)
PaintShop Pro (Score:2)
I thought PaintShop Pro was a Corel product, and "Open PSP" was GIMP.
Ideally (Score:5, 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.
Re: (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'
Re: (Score:2)
At the high end enterprise level they can be used for remote configuration
Why at the enterprise level? Most of the time the difference between the enterprise level and the consumer level is that we don't do things like this on the consumer level because we didn't pay the money for enterprise level hardware.
Remote administration independent of the OS or whatever my parents did to screw up their computer this time? Enterprise grade features for cheap home headless servers?
Where do I sign?
Re: (Score:3)
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: (Score:2)
They had over cook protection a decade ago without all these backdoor shit.
How do you know? If the cook protection was done on some 5p off board microcontroller it would be fine. Being on the host CPU, it's always been able to execute arbitrary, unverified code with access to the entire system and integrated peripherals.
Re: (Score:2)
The IME does some useful stuff like allowing you to VNC into your headless server's BIOS. It's far from useless for a lot of people, the issue is that you can't completely disable it.
Re: (Score:2)
The IME does some useful stuff like allowing you to VNC into your headless server's BIOS. It's far from useless for a lot of people, the issue is that you can't completely disable it.
I get BIOS over serial (over LAN) on old Dell servers because they have an IPMI chip (Dell calls it the BMC - baseboard management controller I believe). I can completely disable this if I want to. It doesn't need IME (at least older versions don't.)
HP's equivalent is called "iLO" (integrated lights out). Not sure if that taps into IME.
Slashdot stories about reddit posts? (Score:2)
Slow news day? When some random internet citizen complains about a manufacturer not open sourcing part of their platform on Reddit it qualifies for news?
Re: (Score:2)
There is more than one person complaining and asking. And to true nerds the response amd gave made it news.
hackable firmware hurts everyone (Score:2, Interesting)
If AMD embraced open firmware, it would make a huge difference in numerous markets: obviously cloud and web-hosting, but also HPC (my field).
Not likely to happen (Score:1)
As I understand it, the AMD PSP is basically ARM TrustZone technology with a proprietary wrapper around it. Even if AMD release all of their proprietary code it would be useless without ARM opening up TrustZone, and seeing as how ARM makes all of its money via licensing deals I highly doubt they would open source one of their crown jewels. Bottom line, if you don't trust the AMD PSP then disable it in your system BIOS and ensure your OS has not installed a kernel driver for it. If you are really paranoid fi
Must be open source to succeed. (Score:5, 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.