Slashdot Mirror
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?
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.
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.
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.
The creatures outside looked from Alt-Right to Antifa; but already it was impossible to say which was which.
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?
Cloudiot: A person who does not see offsite storage as a way to lose control over access to his or her own data.
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.
**Life is too short to be serious**
Doesn't Sony own that?
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.
The creatures outside looked from Alt-Right to Antifa; but already it was impossible to say which was which.
Turns out it uses ROT13.
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.
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?
Cloudiot: A person who does not see offsite storage as a way to lose control over access to his or her own data.
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).
The creatures outside looked from Alt-Right to Antifa; but already it was impossible to say which was which.
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?
If AMD embraced open firmware, it would make a huge difference in numerous markets: obviously cloud and web-hosting, but also HPC (my field).
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 ARM Cortex A53 CPU?
I thought PaintShop Pro was a Corel product, and "Open PSP" was GIMP.
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 fire up a kernel debugger, dump all of your PCI devices and ensure that the PSP doesn't show up in configuration space.
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.
I only understood the GP post after reading the reply by kB here!
Mod me up, if you did too.
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
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.
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
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 had over cook protection a decade ago without all these backdoor shit.
They intentionally bundle critical codes together with backdoor codes so the system won't function without the backdoored blob.
Defective by design.
ThinkPenguin's been funding a modular computing solution called EOMA68 (ie the standard) that'll bring down the cost of designing and manufacturing computing devices built around standardized modular computers. This is making possible computing devices that are completely free- unlike Libreboot'd computers- which are a bit better-but far from the perfect or even a real solution desired long term (Libreboot is limited to 10+ year old devices that don't have the technology being described here).
There is already a laptop, desktop, and card which has been designed around EOMA68 and a successful crowding funding campaign to manufacture the first run of card, laptop, and desktop. The first card is shipping to those who partook in the crowd funding campaign in April. The card is itself a computer and does not come with CPU micro code or any sort of equivalent to the intel management engine firmware. The laptop has a keyboard and LCD controller where the code is fully available. There are no proprietary bits needed to boot like with many Raspbery Pi class devices. While the initial card isn't intended to compete with Intel/AMD in terms of performance the standard will enable much faster 4 and 8 core cards that are coming out in the near future to be backward compatible with any EOMA68 designed laptops, desktops, tablets, phones, routers, and similar devices.
We've put up with hostility on this front from Intel/AMD long enough. The future is elsewhere.