Oh, I'm absolutely in favor of tamper-resistant hardware security modules.

But I also want the freedom to turn them off. If my threat model prioritizes despotic governments with the ear of AMD/Intel/ARM Licensees over, say, phishing rings, I should have the freedom to roll the dice if I so choose.

As of now, I don't have even the choice.

Sorry, I don't understand how this prioritizes despotic governments over phishing rings. Could you please clarify that?

I think the goal here is two things:

1. Allow organizations that want a trusted execution environment to refuse to boot if the OS is not signed properly, to prevent risk of unapproved software execution.

2. Prevent attackers with physical access to the device from booting an unapproved OS that might be meant to extract encryption keys, or otherwise extract or tamper with data.

These are very specific attack vectors that large enterprise customers are asking for to protect their data from malicious insiders, or just anyone with physical access to the datacenter and bad intentions.

That it might be used to prevent Linux from loading is simply an unintended consequence.

I believe points 1 and 2 could be addressed by implementing a trust-on-first-use model whereby the customer can set an initial signing public key for the PSP, which is then used to sign specific boot parameters.

That way, as the customer, I can tell the PSP that I'd like to either require PSP-mediated secure boot, or permit boot if the PSP is disabled. OEMs and vendors selling to enterprise customers can pre-sign it for convenience, and tinfoil hats like me can disable it. Everybody wins.

But we don't even have the choice.

No, it doesn't work this way.

CPU has various modes that are typically switched when booting. It could allow to control it before the system boot without forgoing security.

Unless... that "security" is from the users that own it.

The security also needs to protect against an attacker that has physical access to the device.

This is necessary to prevent things like extracting encryption keys.

One of things I was taught is that you can't really protect if there is a physical access. Yes, you can make it harder, but that's pretty much it. That's why anyone who is serious have multiple layers of security.

Take for example Google data centers, you need access to enter the facility and access to whatever you supposed to work. There are security guards which will follow and stay with you while you are performing your work.

The mechanisms in the CPUs are there to protect CPUs from their users. Let say again you are a Google and are planning to use this technology. Why would you trust a third party to decide (by signing) what can run and cannot run on the CPU. What if that 3rd party happens to be your competitor. The issue is that person/company who owns the CPU doesn't have full control over it, they can't load their own certificates and use them for signing. They need to trust 3rd party with it.

From someone that doesn't know anything about this: Is it impossible for malware to modify that boot code?

Yes, that's why things like UEFI were invented to secure the hardware.

Those things are not necessarily bad, the problem is with having control over what your computer runs. It's about whether you decide that or a 3rd party that you might not necessarily trust.

If things are modifiable before the machine boots, and can't be modified once system has booted, then malware should not be able to modify it.

Obviously not. Except when it can. (joke..)

You can google around for secure boot, trusted boot, chain of trust, etc. Breaking secure boot is the biggest vulnerability a device can experience (e.g. Apple will pay you the most money for this type of break).

This is more like a fuse that can read and modify the memory of the computer it delivers power to, is accessible over the internet, and for which you cannot get the source code let alone run your own code on it.