You're conflating two different things - AMD's Platform Security Processor (PSP) and Platform Secure Boot (PSB). PSP is broadly equivalent to Intel's ME, but lives on the CPU package rather than in the chipset. PSB is equivalent to Intel's Boot Guard, a feature that verifies that the system firmware has a valid signature before letting the CPU boot it.
Both Boot Guard and PSB prevent you from modifying the system firmware (and, say, putting Coreboot on there), but because Boot Guard is implemented in the ME, and because the ME is in the chipset, not the CPU, you can take CPUs out of Intel-based systems and transfer them to somewhere else. If you do the same with a PSB-fused AMD, the firmware on the new board won't be signed with the same key and it'll refuse to boot.
None of this technology provides any real way to prevent you from booting Linux. If vendors wanted to do that, they could already just ship firmware that only supported the Windows signing key and didn't let users enroll new keys. They don't need PSP, ME, Boot Guard or PSB to do that.
You said it: it prevents you from booting a custom firmware. If the manufacturer decides to lock down the stock firmware for only booting Windows (something that is not absurd and some manufacturers already attempted in the past, and keep in mind that Microsoft is requiring TPM and secure boot with Windows 11) you are basically screwed. You can't boot Linux with the stock firmware and you can't change the system firmware.
And given that is firmware, it's worse than that: the manufacturer can with a firmware update remove (that you can't downgrade thanks to all this security bullshit) the possibility to disable secure boot and revoke the keys used by Linux distributions. Reason why I tend to never update the firmware of computers (as to me the firmware is just a bootloader to GRUB that then boots the operating system).
The real thing is, we don't need this kind of security. We don't need ME, PSP, PSB, TPM, and all kind of bullshit. I've never herd of an attack in real life that exploits the boot process. When 99% of computers runs Windows that is full of security vulnerabilities, and nearly half of them even a no longer supported version of Windows, the other half a non updated version because updates are a waste of time.
A computer that requires the firmware to be replaced to boot Linux is already at the point where 99% of users are just not going to install Linux (I've personally ported Coreboot to two of my laptops, and even I would never buy hardware that required me to do that before I could run Linux).
And, well, you may well have never heard of attacks that would be mitigated by these technologies, but I have. Firmware-based attacks have existed for over a decade, and the Hacking Team leak included a firmware implant targeted at some ThinkPads. Do I think most users need to worry about this? No, I don't, and I don't know that there's enough people who do need to worry about this that it should be the default (I have thoughts on this, I'll write them up later this evening). But to deny that some people do need to worry about this is just inaccurate.
And Microsoft has required secure boot and TPMs on all certified client systems since Windows 8.1. Almost all shipped hardware already has all this functionality. If Microsoft had any interest in being evil here, they've had the opportunity to do so for years.
Anyway! Even if you can't replace the firmware, the secure boot database is in an unprotected variable store, so you can just replace it even if PSB is enabled. You're welcome.
Ok, as promised, I wrote up my thoughts at https://mjg59.dreamwidth.org/58424.html . I think with a few small tweaks Boot Guard could be turned into something that offered the same security benefits without being as user-hostile. PSB may require more work in this respect, but it should be technically possible to achieve the same outcome.
> And, well, you may well have never heard of attacks that would be mitigated by these technologies, but I have. Firmware-based attacks have existed for over a decade
This is a pure cash grab by Lenovo and AMD, not about mitigating attacks.
If this were about platform security for the benefit of the owner, it would not be permanent, nor enabled by default. All this does is create more e-waste and nuke resale value for Lenovo systems and Ryzen CPUs.
Lenovo has been increasingly slimy for years now (I guess everyone forgets that they've been caught distributing spyware in their products multiple times?) and this is just yet another stop on the road.
If it's not permanent then it doesn't work - any plausible mechanism for allowing it to be disabled can be triggered by whoever's replacing your firmware (which makes AMD's approach somewhat bewildering here, given that you can just replace the CPU). But yes, I agree that enabling it by default is probably the wrong approach here.
> The real thing is, we don't need this kind of security
This is a real argument. While it might make sense for cloud computing for the client to verify system integrity, malware that modifies firmware is not the largest blip on the radar in these times. A good protection is actually the numerous different manufacturers.
I agree, these technologies aren't primarily for security, they are to enforce how devices are used.
It's not the largest, but against advanced targets who have a chance of detecting other attack vectors, it's a realistic threat. "We don't need this kind of security" is probably true for specific (and even broad) definitions of "we", but it's not universally true and it's not an argument for the technology not existing. Like I said elsewhere, I'm not convinced that the way it's currently being deployed provides anywhere near enough extra security to justify the loss of owner control, but we shouldn't conclude that it means this technology has no legitimate use cases.
> If you're a journalist or an activist dealing with governments that have a track record of targeting people like you, it should probably be part of your threat model.
But considering what we know about the NSA, at least Intel's Management Engine is likely backdoored. So any anti-USA journalist/activist has probably to worry about that too. And an even bigger threat is industrial and diplomatic espionage of non-USA companies and countries using these processors.
(Also could be extrapolated to other countries' secret agencies for potential Huawei, Russian processors, if those ever get popular, like Huawei's control over EU's telecommunications.)
With we don't need that kind of security I was talking about average home computer user (the one for which the personal computer was created!) that buys a computer to use it for normal everyday tasks.
There are situations where that kind of security is required, of course, but they are not something that you should worry about if you use the computer to watch YouTube videos and thus I don't think that makes any sense at all to be present on a consumer PC.
Then I believe it prudent to make such security optional. But enforcing secure boot to me is currently a Microsoft DRM feature, despite the otherwise sensible security consideration that went into the development of it.
Especially if you extend features like remote attestation, it is more about user control than user security.
Both Boot Guard and PSB prevent you from modifying the system firmware (and, say, putting Coreboot on there), but because Boot Guard is implemented in the ME, and because the ME is in the chipset, not the CPU, you can take CPUs out of Intel-based systems and transfer them to somewhere else. If you do the same with a PSB-fused AMD, the firmware on the new board won't be signed with the same key and it'll refuse to boot.
None of this technology provides any real way to prevent you from booting Linux. If vendors wanted to do that, they could already just ship firmware that only supported the Windows signing key and didn't let users enroll new keys. They don't need PSP, ME, Boot Guard or PSB to do that.