Well, yes and no….
These chips that hold and execute a BIOS or device firmware usually are incredibly simple. They contain a single binary that automatically executes as soon as the chip is powered on. When these chips are written to, it’s not like copying a file to NAND flash (I wish it was that simple sometimes…). Because of this, if you want to change even a tiny part of that binary you have to recompile that binary and flash the entire contents of the chip.
That’s why there’s usually a big “DO NOT TURN OFF YOUR COMPUTER WHILE FLASHING OR YOU COULD BRICK IT” warning when using consumer BIOS update tools…
I’m sure you’ve had a BIOS update fail. If you haven’t, then you’re lucky, and you need to tell me your secret .
Flashing BIOS and firmware chips sometimes goes wrong, and each flash does take its toll on the lifespan on the chip. That’s one of the reasons why manufacturers try to limit the number of BIOS updates they release to a couple of times a year, and urgent security updates.
But that’s only part of why I’d be surprised that it would alter the device’s firmware and remove a feature permanently. The other part is the logistics of actually doing it that way.
If that’s what it was actually doing, it would need a binary to flash to it. Where would it get it from? The CPU? Wouldn’t that mean that a full backup of a binary without vPro functionality was stored somewhere that the CPU/NIC/BIOS had access to?
What would happen if that hardware was sold to someone else, and that someone actually wanted to use vPro? How would they get it back into the device firmware?
And if you could just “reflash” the device firmware, what would happen to the serial number most likely stored within that binary?
Intel would have an insane number of their vPro devices sent back to them because the customer bricked them….
I’m just saying, it would be so much easier to keep the code for vPro on the chips in the binary, but have it compiled with an option to not execute it. It would also avoid unnecessary writes to the chips, prolonging their lifespan.
This is why I would be surprised if that’s what was actually happening….
And microcode updates aren’t actually stored on the CPU, at least not with Linux. They’re loaded onto the CPU at boot time, along with the Linux kernel, and they are gone as soon as power is lost to the CPU, and need to be loaded on next boot.
Maybe Intel and AMD have some kind of arrangement with Microsoft, and they allow flashing of the internals of the CPU while running Windows. That’s possible. It wouldn’t be the first time (we need more BIOS updating tools released by vendors for Linux and BSD. I mean, they probably used Linux/BSD to build the damn BIOS anyway!)
——
Basically being stuck inside a “docker container” behind a paywall on someone else’s computer, and calling it “the afterlife”.
That would easily be Richard Stallman’s definition of “hell”
A good story, though…
And a very accurate depiction of what “technology” in society has become….