Quoting from Libreboot:
As such, it has the ability to hide its own program code, scratch RAM, and any data it may have taken and stored from the lesser-privileged x86 system RAM (kernel encryption keys, login data, browsing history, keystrokes, who knows!). To make matters worse, the PSP theoretically has access to the entire system memory space (AMD either will not or cannot deny this, and it would seem to be required to allow the DRM “features” to work as intended), which means that it has at minimum MMIO-based access to the network controllers and any other PCI/PCIe peripherals installed on the system.
At least the Neo900 developers tried to isolate the baseband processor as far as possible:
My issue with that is that I don’t see how it prevents AMD from releasing a super stripped down (essentially disabled), but still closed source version of the firmware. There may very well be a valid justification for not doing so - I just don’t know.
An even better approach would be to allow the system to run without the firmware at all. If I remember correctly, some Intel machines will run for 30 minutes without the firmware, but will shut down after the time elapses. If true, that at least proves that it’s not essential for system operation.
In the case of Intel, surely they could have disabled this 30 minute timer on the consumer CPUs (just like how they disable ECC support).
There are also some additional problems. Intel ME is used by Linux quite heavily (rather than talking directly to the embedded controller) which means that certain things can become quite flaky. I have Coreboot on my X220 with me_cleaner, and my machine seems to freeze randomly (it's definitely not the 30-minute timer, I just think it's IO being deadlocked for some reason). While your machine may appear to work without ME, there are almost certainly features that won't work.
Are you sure? Links or commit IDs?
I also believe that I've read somewhere that the reason you need to use tools that talk directly to the EC to modify things like battery levels with coreboot (as opposed to the "standard" tools used on stock machines) is because of the lack of those interfaces for Linux.
I may be mistaken about the latter, but it is definitely true there are useful things that Linux does provide support for (and might use internally, I'm not sure).
100% of large corporations that I know of which have an opinion on these things (all one them) laugh Intel's AMT and are glad they have done what they can to disable the firmware (they can do more than you or I can do).
Giant corporations are perfectly capable of controlling their own laptops.
Something similar happened just a few months ago: It all started with this article:
which was considered as sensationalist. Just a few days later facts appeared in less sensationalist language:
> https://www.heise.de/security/meldung/Sicherheitsluecke-in-v... [in German]
> https://www.heise.de/ct/artikel/Tipps-zur-Intel-ME-Sicherhei... [in German]
An analysis of the bug source:
What finally happened: A set of firmware updates was released by Intel to the hardware vendors. These were installed by careful admins and users. After this the story mostly got forgotten. So the bug source was indeed probably a nightmare for Intel - but the public did not really care for it except for some nerds.
Back in the days of the 486SX/DX, it was far more normal to sell processors with features disabled for less money. Why don't AMD and Intel want to monetise their management features?
They do, most machines don't have remote management firmware and chipset features installed.
As for why the ME is present on all hardware - it would be a shame if your consumer CPU couldn't securely decode super-4K-full-ultra-HD videos, right?
Besides DRM, I think the ME is also used for SGX.
Intel(R) Software Guard Extensions (Intel(R) SGX) is an Intel technology for application developers seeking to protect select code and data from disclosure or modification.
Maybe Intel wants to create some "ecosystem" of software utilizing SGX (because vendor lock in) and for that they want as large hardware base as possible. That's just a guess, I haven't read Intel docs and IDK if any off-the-shelf SGX software exists yet, but I have seen similar ideas in some AMD PSP PDFs.
FWIW, Intel Wikivertisement on SGX:
The introduction of SGX has a large impact on the security industry. It shifts how security is being achieved and lowers the attack surface area of projects. One example of SGX used in security was a demo application from wolfSSL using it for cryptography algorithms. One example of a secure service built using SGX is Fortanix's key management service. This entire cloud based service is built using SGX servers and designed to provide privacy from cloud provider. An additional example is Numecent using SGX to protect the DRM that is used to authorize application execution with their Cloudpaging application delivery products.
The last one seems like something that could benefit from SGX on end-user devices: https://www.numecent.com/cloudpaging/
Yes, especially when you stand to lose billions of dollars in contracts with the DoD by removing the remotely exploitable ME from processors. It's probably that kind of economic loss.
Is there even any question at this point? The NSA doesn't want them stripping out their backdoors. Remember when Intel 'accidentally' managed to screw up a simple string comparison in a way that would conveniently allow remote access without password?
Which is why it can't/won't be disabled.
"Not that anyone could have seriously expected that.
If AMD makes a business decision to possibly open source the PSP now or in the near future, the first results will be visible 2-3 years later, at best. However, it is VERY likely that there are legal barriers, such as 3rd party code. Maybe they are using a 3rd party RTOS that they cannot publish the sources of? Or maybe some DRM part of the PSP firmware can't be published?
What I'd personally like to see is a minimal PSP implementation (without any noticeable features) that's Open Source, with reproducible build process and a binary of that signed by AMD."
There are 3rd party efforts to produce something similar on Intel platforms:
How many of the people complaining about the lack of PSP source code are willingly running a closed source GPU driver? How many of them are running Windows, Mac OS or some other closed source operating system?
It reminds me of when people were blowing a fuse over the linux kernel's use of Intel's built-in PRNG.
I'm all for open hardware design but focusing on these particular modules is a bit counterproductive I think, if tomorrow AMD or Intel were to release CPUs without this particular "feature" the surface of attack would not shrink massively.
Hardware is open or it's not. Nowadays it's overwhelmingly not open, so you have to blindly trust AMD, Intel and the variour ARM SoC vendors not to fuck you over and having the PSP source code wouldn't change much about that.
 They probably do.
You can get a machine to run reasonably well without relying on closed source graphics drivers. If your GPU firmware is evil in some way, it's on your GPU and you can be pretty confident it won't compromise the rest of your machine or your network. If a driver is compromised, there will be signs of abnormal behaviour (you can inspect what software on your machine is doing at runtime).
With AMD's PSP or Intel's ME, there are no such limitations in how bad things can get. These things could take all the data you have in memory, connect to some shady network location and dump all the data. All the while there is no trace of that activity in your OS, because of none of this nonsense lives in your OS.
How can you be confident of this when your GPU can DMA into anything?
at least for Intel processors only the more expensive ones support IOMMU (Intel VT-d). On the other hand for modern AMD processors this feature seems to be commonly supported.
...which is obviously not the world we live in.
It makes it a bit more difficult to implement such backdoors of course, but it's still perfectly doable.
Again, I'm happy that people value their privacy and campaign for more open source but it seems a bit myopic to put all our attention on this tiny part of the problem. The risk is that if tomorrow AMD decides to actually open source the PSP many people will think that we won and the battle is over when we've just removed one of thousands of possible attack vectors.
Because it's an ongoing effort. Years ago people were running GNU software on proprietary kernels/operating systems.
You can't get to fully free and open hardware in one step. Firmware is the next battlefield, and its an area that hardware manufacturers have been winning. The firmware on a modern machine is orders of magnitude larger than it was 10 years ago, while provided essentially the same features. More and more closed source code is running on your machine.
If we don't push back sooner or later your linux install will only be running in a virtualized environment provided by the proprietary OS running in "firmware"
Also I don't really see how having access to the PSP source code would factor into that. As long as you can't prove that the management engine is really running that code unmodified and there's no hardware backdoor to change its behaviour it won't really get you anywhere.
It seems like many in this thread get stuck on the idea that Intel "already has the ME, so what's the point?"
The point is, I prefer Intel due to performance reasons. But I would have changed over to AMD permanently if they open sourced the PSP code, or if they removed the PSP entirely. That would have been their one competitive advantage, and now they've shat all over it, and lost many potential customers.
Yes, I'm sure people are turning away in droves from the most competitive AMD processor in a decade because they won't open source their version of ME.
It's similar to the gaming enthusiast market, though a lot smaller. You can market to that small segment for a big win, because gamers will shell out for the newest GPUs, talk up the hardware online, which leads to increased sales. If AMD would see the benefit of working with this privacy-conscious segment of the market, I believe they would also see, not a major, but also not an insignificant uptick in sales.
Even on raw performance AMD is pretty close to comparable (i.e. I ran my top of the line intel i7 machine along side my top of the line AMD machine and there was no noticeable differences).
tl;dr: the PSP is a full computer that lives between the instructions that get sent to your CPU and what your CPU actually executes. It's obviously a huge security problem, because if a backdoor in the PSP gets exploited, you cannot trust your computer in any way, and there is no way for you to verify whether it is being exploited or not. AMD said they might open source it, but even that wouldn't do much to establish trust.
The "no security through obscurity" theory is not entirely true in the real world.
When you push up the cost (money and skill) of a hack then hackers will attack weaker components and so the likelihood of a hack is smaller.
This code is highly secure and would require an enormous amount of specialist knowledge, equipment, and time to extract, analyze and exploit.
The effort involved rules out rational profit motivated individuals because the costs are too high and there are plentiful opportunities for lower cost exploits.
No company releases the source for their DRM code except to legitimately interested parties in controlled circumstances and that is the correct policy from a security perspective.
EDIT to expand a bit since some people seem to be missing the point: hypothetically, GP might have preferred Intel on narrow technical criteria, but have been willing to override that preference for the sake of transparency. No transparency difference, no reason to override.
Fwiw I'm not ready to use open-ish ARM/POWER exclusively, but AMD/Intel'll have to contend with that soon(tm)
[Answer to parents EDIT]
I'd argue the effective technical difference set between AMD & Intel is growing ever narrower, and aside from brand fidelity there is very little reason for a consumer to have non-moral preferences to one or the other manufacturer.
Because Intel's ME/AMT sure as hell isn't any better.
It is not attached to ARM's CPUs, not it is mandatory, it is just something that SoC developers can pick up and implement however they want.
Still, some boards/devices may lock it down, for example by code signing.
If you are making something with the SoC.. it's probably safer to buy the locked down version of the SoC than to mess about with TZ or to leave it open.
The CPUs from Intel/AMD are much more than a simple CPU, they are a complete system on a chip with a lot of more features that go beyond processing power for your system. On the other hand, an ARM CPU is just a simple CPU.
If you want to make comparisons, a more correct one would be between the Intel/AMD CPUs and a Snapdragon processor.
AKAIK, only the Versatile/RealView style boards that an SoC manufacturer would get directly from ARM come with bare ARM chips. Anything other than that is an SoC.
My point is that an Intel/AMD product is a complete solution while an ARM product is just the very basic implementation of a CPU.
ARM doesn't mandate on anything related to the SoC except for the CPU, everything else related to PCI buses, memories, physical implementation, chipsets, etc, is up to the SoC developer to decide and implement.
There's simply no way to get a completely trusted computer stack nowadays, short of assembling it by hand using discrete electronics. It won't run very fast though...
I guess an alternative would be to crowdfund the production of an open source CPU then take a few samples and send them to people with an electron microscope and a lot of patience to make sure that the silicon really matches the design and wasn't tempered with in the fab.
Do they simply use the features these processors and their OSes provide? Do they get a special deal to look under the hood? Something else entirely?
As far as I know Google mostly uses Xeons in their server farms, but also some POWER9 servers (for example cf. https://cloudplatform.googleblog.com/2016/10/introducing-Zai...) - many people say this is "some kind of Google's insurance against Intel/x86":
> Do they get a special deal to look under the hood?
It is well-known that the largest buyers of Xeons (plausible names are Google, Microsoft, Amazon, Facebook, Alibaba and some others) have access to special versions of Xeons that have special features enabled that are disabled in the versions sold to the general public. One article giving hints into this direction is
One such feature that is talked about is having access to an FPGA (why did Intel buy Altera again) and it is well-known that Microsoft uses FPGAs for Bing:
> https://www.golem.de/news/microsoft-weil-cpus-zu-langsam-sin... [German article]
With this information I would bet that they have a special deal to look under the hood.
I really wish it could be disabled because once these talented people are in; you, your antivirus or operating system would never know.
That makes the idea of using technology to gain some sort of privacy from state level actors with infinite resources and man power to thwart you a total nonstarter that can at best deliver a false sense of security and at worst more serious consequences for those who may need it.
The bottom line is established power is paranoid and wants to monitor all communication whatever they may proclaim publicly and it appears from hind sight and what we now know they have always done it.
Where can I buy a RISC-V computer?
I.e. not only some microcontroller board "which is just a much faster Arduino", but a board that has the usual capabilities that one expects from a computer such as GPU, ethernet, USB jacks, audio in/out (either audio jack or via HDMI), possibility to connect a SSD, and perhaps an SD card slot and RAM slots to increase the RAM if one desires.
This helps mitigate attacks like persistent rootkits that alter the OS to mask the presence of malware.
However, as a supervisor processor, the PSP is also a risk itself. If a well funded state setup a shipping interdiction on import or export, they could alter the PSP to insert their malware and we wouldn't be able to audit it.
This is a gift from all of those mobile SoCs that might've gotten signed bootloaders initially just to protect the subsidy. Part of the overall "death of the general purpose computer" (see Doctorow for more).
Maybe a side-channel attack could help reveal the PSP firmware or other vulnerable design elements. But I'm pretty pessimistic -- the number of organizations/people capable of investing in the time and equipment necessary to do this is low.
If you've ever used a server they often have a nice feature where you send an authenticated command to them on a certain port and get it to shutoff, turn on, reboot, whatever. This is run from the PSP on AMD processors.
Or maybe it has a remote backdoor put there by the NSA (or maybe just escrowed command and control keys) and ANY AMD device connected to the Internet can be controlled remotely by them at will. We have no way of knowing.
Or if TLAs don't worry you, then maybe the code running on it has a 0-day vulnerability and every server out there is vulnerable to remote code execution + the ultimate privilege escalation and we don't know about.
Or if that doesn't worry you, then maybe it'd at least be nice to be able to program it yourself and add new features, bug fixes, etc.
Those are all good reasons for requesting open source PSP code.
Is there any good alternative to AMD or Intel processors? Like more open ones?
IBM makes POWER CPUs and you may assume that -- unless they've disclosed something -- no one other than IBM and the NSA really know if there are any unauditable "support" processors on the die. Beyond that the Raptor site mentions that there are still some bits you don't get to know about their system: "several pages will be redacted on the public schematic due to mandatory NDAs with a few of our support silicon vendors."
Everything else is SOC/MCU stuff; nothing that approaches the capabilities of these Intel and AMD CPUs. You could hold out on older pre-ME/PSP systems until RISC-V goes through enough evolution and market success to achieve parity with then-contemporary devices, sometime around 2035 I'd guess...
Answer to your question is, in most cases, simply no.
RISC-V just refers to the ISA, right ? An implementation by a vendor may still have ME/PSP like stuff, just like the x86 ISA has nothing to do with ME/PSP.
The BCM2835/BCM2836/BCM2837 that is used in the RPi is made by Broadcom, not Atmel.
Here is where open source is different from free software, and this is why free software is better than open source.
Say for example, ddwrt, a very popular firmware used in several routers. Or simply saying, Linux (kernel) + busybox, a very popular combination of some open source codes used in several embedded systems: They are simply open source when they run on those systems, not free software. You can't replace their code with some (custom) versions most of the time.
All you get is the source code, you may not be allowed to run custom version. You may not even be able to confirm if the code they gave is the code that is actually being run on those devices.
As always said, that is enough to fit to the terms of "open source". And yes, just another reason why free software is (almost always) better than open source.
Hence I'm a bit pissed off right now. But even though I was dumb enough to believe, at least I was smart enough to wait for it, and did not waste my money.
A good FAQ is done by LibreBoot: https://libreboot.org/faq.html
Intel already has Intel ME.
The thread was basically everybody saying they would buy AMD if they release the code because they'll be the only friend CPU towards the open source community.
This was actually awhile ago, I was the reading the thread too.
Telling someone if they don't like their processor choices to "build their own" is like telling someone to build their own ISP/Telco service if they're not happy with the sole Comcast offering in their area.
I am pretty sure that most EE/CE students at some point or another implement a basic processor on a fpga. That being said, I am not sure how many of them would be able to build a "modern" one.