SoylentNews is people
SoylentNews
Submitted via IRC for TheMightyBuzzard
Since the launch of AMD Ryzen, a small piece of hardware that handles basic memory initialization as well as many security functions has been the center of some controversy. Called the Platform Security Processor (the "PSP" for short) it is essentially an arm core with complete access to the entire system. Its actions can be considered "above root" level and are for the most part invisible to the OS. It is similar in this regard to Intel's Management Engine, but is in some ways even more powerful.
Why is this a bad thing? Well, let's play a theoretical. What happens if a bug is discovered in the PSP, and malware takes control of it? How would you remove it (Answer: you couldn't). How would you know you needed to remove it? (answer, unless it made itself obvious, you also wouldn't). This scenario is obviously not a good one, and is a concern for many who asked AMD to open-source the PSPs code for general community auditing.
Bit late to the reporting but we haven't covered it yet, so here it is. And I was so looking forward to a new desktop too. Guess this one will have to stay alive until ARM becomes a viable replacement.
Previous:
The Intel Management Engine, and How it Stops Screenshots
Intel x86 Considered Harmful
Of Intel's Hardware Rootkit
Intel Management Engine Partially Defeated
EFF: Intel's Management Engine is a Security Hazard
Malware uses Intel AMT feature to steal data, avoid firewalls
(Score: 0) by Anonymous Coward on Sunday August 20 2017, @03:08PM (3 children)
Can't someone decap one of the processors and read the contents of PSP?
What about using a electron microscope?
(Score: 0) by Anonymous Coward on Sunday August 20 2017, @03:49PM (1 child)
Ask the NSA.
(Score: 2) by requerdanos on Sunday August 20 2017, @11:19PM
Asking publicly in a forum buzzing with keywords about encryption and backdoors* == asking the NSA directly.
* or anywhere mentioning bomb, president, allah, terrorist acts, holy fire, etc. I'm sure they don't (always) read it live over the wire, but they sure flag it for review. Hi guys--Go Redskins.
(Score: 0) by Anonymous Coward on Sunday August 20 2017, @04:49PM
The stored code is encrypted, signed with a master key of which only the private key is available in the cpu. So you COULD in theory pull out the decryption key and decrypt the code stored in prom in the CPU or an image from flash/update file. However you may or may not be able to figure out the image, and since you can't modify it without failing the checksum, it becomes a lot more difficult to debug it to attempt to reverse engineer what sections of it do. There is a series of blog posts somewhere covering what was required to reverse engineer the information needed for the me_cleaner utility up on github. Suffice it to say it took multiple people 3-5 years including numerous false starts to get far enough along to realize they could zero out sections of the firmware to disable features, and what regions had checksums in them that had to be available and what they were summed against to ensure the system would boot and stay booted up while disabling all the components that (hopefully!) contained the features of concern. And even then said modifications would result in the loss of the software TPM, which nobody should really use since the key extraction I mentioned in previous threads is completely possible if either a bug or intentional backdoor were inserted into that code. But as it is if you have software that requires TPM attestation to run, your only choices are not to run it, or open up the potential for TPM code related backdoors on systems with the Intel AMT/ME code running on them. (Which there are systems with seperate TPM chips, like many retail motherboards had/have headers for, basically all Intel notebooks use the software TPM in place of a hardware model, hence the loss of all TPM/attestation features if you remove those regions using me_cleaner from your firmware image, which btw, is not a trivial task itself, since the ME also blanks and/or locks memory ranges in the SPI flash leaving you unable to reflash from firmware from in-system without a valid checksum. Thankfully external flashing still works so long as the correct checksums for ME components exist in the modified firmware image.