It's interesting to keep this in historical context, IMO.

You're Intel. The year is somewhere around 1989. Your hardware interface that you export to regular software has gotten complex enough that you want to implement some of it in some kind of software that you can implement at a higher level than just logic. You also maybe want your hardware partners (ie. motherboard and system manufacturers) to be able to change parts for their implementations. Additionally some of this code might eventually end up being hard real time with the possibility of damaging the chip if it doesn't run at the correct window (think power management). You don't have the area budget for rewritable microcode of the size you'd want; this code has to live in DRAM.

You look around at the system software people are running on x86. At the highest quality you've got OS/2, and it goes downhill fast from there. Most end users are running DOS (from several vendors). So you write a higher privilege mode that runs underneath DOS, can actually be pretty close to a tiny RTOS kernel, and document it. But the whole point is to be relatively transparent, and definitely inaccessible to kernel mode, which you don't trust to pull its own pants up after it uses the bathroom.

Then later, when your corporate vendors are asking you to secure the boot chain, it only makes sense that this mode is also cryptographically signed.

And I think this is a more interesting story (and probably closer aligned to the truth). That is, we can get to an anti-user feature that can't be truly owned by the final customers through small steps where each felt like a pro-user customer product decision.

On commodity PC platforms there are both upsides and downsides of having runtime firmware in a special mode like SMM (or the secure world on ARM64 which is a whole other topic). For hardware errors (e.g. mapping row/bank/column to PA), platform workarounds, certain platform power states, power fail notifications, backwards compat, (unfortunately) extending AML by writing to port B2, etc it can be beneficial for hardware+firmware vendors to have a runtime execution environment that doesn't require shipping OS drivers. Lately the downsides of this are growing and historically security hasn't been great.

That being said, there are benefits of having SMM protect firmware integrity from a malicious/compromised kernel. On most AMD64 platforms, SPI flash can only be written to by SMM and that is a foundational piece of the PC security model (FW update, authenticated UEFI variables, etc). This has nothing to do with copy protection, DRM, or backdoors.

SMM was originally conceived for power management, as it first appeared in the laptop-oriented 386SL. Then it was used for seamless backwards compatibility e.g. peripheral emulation. Unlike e.g. TPMs or other DRM-ish schemes, IMHO SMM was never hostile from the beginning.

I have to agree with your overall take (only caveat being that I know too little about hardware to know if it's well-founded).

The incentives are such that if it's possible to make hardware that's cryptographically locked into being aligned against the interests of its supposed owner, that's exactly what will be, which is why we now have two fully-closed systems (Google Play Services and iOS), one 99%-closed one (macOS -- Apple controlling the 'notarization' signing and showing their willingness to use it for petty reasons proves macOS is closed), and one clearly marching toward the same basic idea (Windows).

What's more depressing is, even if suddenly every court agreed with me, we'd just transition overnight into a leasing paradigm, where vendors would cease to sell devices, only rent them to us. "As the device owner, should we not have the right to govern its use to only responsible purposes and protect it from 'mAlWaRe'?" And the devices would be quickly 'accepted' by the market, as "unmanaged" devices would be locked out of everything, just like you can't use banking apps, streaming apps, or even the McDonald's app, on a rooted/jailbroken phone today.

> Why do CPU vendors implement a mode that cannot be controlled by the user?

It's even worse than that. It's gotten to the point that "operating systems" aren't actually operating the system anymore. Linux is just the "user OS", a tiny blip on the overall system schematics. Just some app to be sandboxed away from the real system.

https://youtu.be/36myc8wQhLo

That says more about your lack of both knowledge and imagination than the vendors.

Intel added SMM for software backward compatibility so DOS didn't have to learn how to suspend and resume on early laptops. Instead of waiting for operating systems to grow support for power management the SMM firmware took over when the user closed the lid. The operating systems of the time didn't know or care and user were happy it worked out of the box. Only later when hardware and software became even more complicated did it stop working reliably.

It was also used to emulate devices in firmware on cheap low-end systems so they looked like well known hardware to existing software.

You can claim it's an evil hack and I would agree, but it wasn't malicious. Also I think you can reasonable assume nobody at the time expected that this hack would last so long or that PC compatible laptops would ever have multiple CPUs.

> Why do CPU vendors implement a mode that cannot be controlled by the user?

Devil's Advocate: can you control every transistor in a good old Z80?

Of course, that's not where the goalposts are. Any piece of hardware will necessarily have limits as to the amount of introspection and manipulation that it allows in the programming model.

What Intel have done is built a "grotto" in the chip that is extraneous and deliberately inaccessible.

It certainly is a vulnerability, because SMM is a higher privilege level than root.

(The fact that there is such a thing as a higher privilege level than root is what annoys people).