> BIOS flashing from the OS has been a thing for a long, long time now. Heck my XPS 13 running Linux even gets BIOS updates from apt-get.
Yes, I forgot to add that point. It's also just as bad as the other options, because it means that the attacker has gained root access.
Using the vendor locking as a method to remedy this issue (an attacker being able to compromise a servers' BIOS or BMC) is basically just fighting the symptoms, not the root cause (which is that inband updates from the OS for BIOS and BMC are generally a bad idea)
> And 99% of that hardware is sold together as a unit. It will hamper repair efforts, as the CPU & motherboard are now effectively a single unit, but it does not effectively kill or even significantly harm the second hand market.
This is generally not true. 90% of the hardware is sold separately, servers are mostly sold as barebones and CPUs without servers. Some vendors offer custom configurable servers and I know from many that they make the majority of their sales from barebones or single CPUs, not configured or assembled systems.
> Nobody is running a datacenter on second-hand hardware anyway, there's no market to cripple there.
Not hyperscalers, no. But many SMEs / SMBs buy refurbished hardware and running their datacenters on refurbished hardware.
With your argument, we could as well say "just toss all server hardware in the bin once it has been decommissioned" which is obviously nonsense, because if there wasn't demand for refurbished server hardware, there wouldn't be a such a big market in the first place.
You can assume that at least 95% of decommissioned server hardware (except HDDs, still too many of them are shredded) gets a second or third life.
As far as I know, Intel does exactly that (or at least allows vendors to do that, I think HP does that)
IIRC, in Intel's case, the chipset has the vendor keys burned into it. This is not an issue, as the chipset is not a part you would remove from the board and use elsewhere.
First, the security argument is nonsense in my opinion.
This "feature" only prevents an attacker from flashing a modified, malicious BIOS on to the server.
But: If an attacker manages to flash a new BIOS to your server, you're already lost. That either requires physical access (which is bad), or access to the OOB / BMC / IPMI (which is equally bad, because those usually have a remote KVM feature, so you could e.g. boot the OS into recovery mode)
It does not prevent any other attacks, because you could still swap out the CPU. The servers usually just quietly burn the CPUs, so you wouldn't notice if the CPUs were replaced by an attacker.
Second, this produces a lot of unnecessary e-waste. About 99% of all hardware (except HDDS) from datacenters is sold on the second hand market.
Locked CPUs are essentially worthlese, especially if buyers or sellers don't know and throw the CPU away because they think it's defective.
Third, this opens up a MASSIVE attack surface.
Imagine if somebody finds a bug im the PSP (Platform Security Processor, a CPU inside the CPU that handles the locking thing amon g other things) and is able to burn arbitrary keys into the CPU.
The attacker would randomly generate a key and burn them into the CPU.
You could permanently kill an entire datacenter with that within seconds.
Or if somebody manages to write a malicious BIOS version and flash it to servers which usually don't have a locked BIOS. This BIOS version would also burn a random key into the CPU with the same result:
You can easily permanently destroy an entire datacenter.
I think this is just AMD's greediness again in the cloak of "improving security"
locking:
At least some AMD CPUs (EPYC, TR PRO, Ryzen Pro) can have cryptographic keys burned into the silicon by the BIOS (Dell and Lenovo do that)
Once a CPU has those keys burned into it, it is locked to motherboards of this specific vendor, because other motherboards don't have a BIOS that is signed with the cryptographic key that was burned in.
PSB: Platform Security Boot
PSP: Platform Security Processor (a CPU inside the CPU which handles e.g. the key burn in process)
This is not correct.
The locks does happen on the CPU level. If the board cannot provide a BIOS with a valid signature from the key that was burned into the CPU, the CPU will refuse to boot (PSB prevents it from booting)
Well, if it's optimised out at "-O3", I usually don't care.
If you have some numerical code you can optimise further (even though you're using "-O3" or "-ffast-math"), things become interesting!
Heck, bugs like Meltdown and Spectre were found. And exploits on the PSP have already been demonstrated, see here https://github.com/PSPReverse/amd-sp-glitch