I've worked on a few SuperMicro servers that bundled OOB/IPMI onto the same NIC that is used for the LAN. 1 RJ45, 2 MAC addresses
I will stab the bean-counter that thought this was an OK idea with a fork if I ever meet them.
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.
> 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.
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.
> I think this is just AMD's greediness again in the cloak of "improving security"
Intel has this same feature. This almost certainly wasn't done by AMD's "greediness" but rather because major customers, like Lenovo, demanded it. And even as a "greed" argument it's a pretty flimsy one. Nobody is running a datacenter on second-hand hardware anyway, there's no market to cripple there.
UEFI capsule updates are triggered by the OS, but don't occur in the OS. The updates are copied to the EFI system partition, and on next reboot the firmware is triggered to apply them. The flashing process involves the firmware verifying a signature on the image before applying it. The reason for this is that the firmware flash is locked down at runtime, and most of it can't be written to outside System Management Mode. Halting the entire OS for long enough to flash the firmware isn't realistic, so it makes more sense to do it in the firmware environment instead. In any case, the net effect is that while, yes, you trigger the update from the OS, the OS itself is unable to directly modify the firmware, and if you try to flash a modified image via the capsule update mechanism the firmware will reject it for having an invalid signature.
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.
No you can't. AMD builds the TPM in to the CPU, with AMD's encrypted memory feature (SEV), in theory you do not have to trust the data center an all.
The CPU boots, loads a verified firmware using PSB, initializes a safe environment in SEV, your entire boot procedure and data is encrypted and safe using FDE and SEV keys stored in the TPM using PCR's.
Nobody is going to care until this happens.
Damn I bet someone perhaps a state player or a well financed group is able to do this, can't wait to see this happen...But how does anyone burn it remotely?
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
The goal of AMD's SEV and other features is that the only way to compromise the system is to tamper the wires between the CPU die and the IO die, that all data going outside the CPU die is encrypted, an extra hardware TPM chip module let you MITM the keys being sent to the CPU, having the keys stored in the CPU using fTPM, and never plaintext / keys leave or enter the CPU via PCIe or memory bus.
the "chipset" is literally just a PCIe/USB multiplexer these days, the CPU has no access to external hardware until after the firmware has loaded, the firmware has routines for turning on the memory and memory controller, PCIe etc, I don't think people understand just how utterly useless the CPU is without the firmware.
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"