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: 3, Informative) by Marand on Monday August 21 2017, @01:15AM (2 children)
You may have a problem with your memory settings, especially voltages. I've been messing with it since March and it seems that a lot of RAM's advertised timings and voltages (especially XMP profiles) are just completely useless. After some trial and error, the only segfaults I'm getting now are from the massive parralel compiles that are intended to cause them and a known problem with some early chips. (Fairly minor issue in practice, but hoping for a microcode fix.) I had to bump the cpu northbridge voltage and the RAM voltages up slightly to get it stable, though. The chips' profile suggests they can run at 1.2v but they'r ridiculously unstable at that, even with 2T command rate. (Early AM4 BIOSes were locked to 1T, which made it even worse.)
If it's that crashy for you, make sure you've got the latest BIOS for your board and start tweaking some. Also, try disabling Core C6 state (a power saving option), it's been reported to help on Linux.
(Score: 0) by Anonymous Coward on Monday September 04 2017, @07:33PM (1 child)
If you have a Gigabyte motherboard, check there isn't a bios update; a recent bios for the 350 series (I think; my memory is not what it was) had some stupid bug - a 0.5 where they meant 0.05 or something like that - which resulted in it basically overclocking the chipset and CPU to the point it was throttling. Apparently they don't test their shit before unleashing it on the unsuspecting public.
(Score: 2) by Marand on Wednesday September 06 2017, @07:04AM
Wow, that's absolutely terrible, and makes me glad I didn't go with Gigabyte. I saw that their Linux support had been pretty bad for the previous generation of boards, to the point that people couldn't even get basic things like USB working without lots of dumb workarounds, and there wasn't enough data at the time to show that they'd improved any for AM4, so I skipped them entirely. Went with MSI instead, because reports of their AM3 stuff seemed to indicate they weren't releasing broken garbage, plus I've had good luck with their hardware in past, so I figured it would be a pretty safe choice.
So far I've been right, and the biggest problem I've had with MS specifically is that they're about a month later than the other board makers with bios updates...but I'd rather have a late bios update than a broken one, so as long as I don't start getting them late AND broken, I'm okay with it. :)
I do need to go back and try testing voltages again, see if I can either get the XMP profile's settings (the 1.2v) stable or get some extra mhz out of the chips. The last bios update MSI put out has a new opcache control option, which seems to act as a workaround for the whole micro-op issue that affects some early Ryzens (mine included). Using it seems to successfully stop the gcc segfaults, and maybe there's a chance some of my stability issues were related to it. Though I think most of my RAM trouble is because I bought when Ryzen was just released, so there wasn't really anything AM4-specific available for RAM at the time. Very little info, XMP profiles based on Intel chipsets, etc., so I've had to work around that.
No big deal, though; I knew there'd be some tweaking and trial-and-error when I chose early adoption, so it doesn't bother me, and the hardware's damn good.