(Seriously, SMM serves either bizarre ILO features that high-end vendors like but are rarely used, or security agencies looking for a layer to hide in.)
Several Intel chipset generations require certain register writes on shutdown (disable busmaster) or they won't _actually_ shut down. Operating systems aren't aware of that. (https://github.com/coreboot/coreboot/blob/master/src/southbr...)
UEFI Secure Boot requires "authenticated variables", which can be updated by the OS (after checking authentication, using a signature scheme). UEFI code resides somewhere in memory, so the OS (or ring0 code) could opt to bypass the verification and simply rewrite those variables. The recommended (but not required) solution is to move variable update to SMM. (https://firmware.intel.com/sites/default/files/resources/A_T...)
Several hardware features are actually implemented in SMM. I've seen SMM-based handling of certain special keys (eg. "disable Wifi" button) where ACPI grabs the event, then traps into SMM using a magic IO port.
I have an APM (ARM64) Mustang, and this takes a rather different approach, but probably not one you'll think is better. The chip advertises 8 x 64 bit cores, but there's a 9th 32 bit core which runs all the time, even when the machine is powered down (although obviously still connected to mains power). It runs a separate firmware, in its own RAM, but can access the main memory at will and invisibly to the main OS.
One way to look at this is it's brilliant that we can just put a tiny Cortex-M3 in a spare bit of silicon and have it do useful management stuff.
It can also do PMU control when the machine is 'turned off'. The alternative is to use an external microcontroller. It is actually quiet useful.
What is your reason for wanting to disable it?
All watched over by hypervisors of loving grace.
How do you know what the firmware does? Is it even possible to inspect it, let alone replace it? It's just another part of the attack surface - not necessarily deliberately, but if there are exploitable bugs in that firmware that can be triggered from the rest of the system, it's another security risk.
Minor quibble: The IME is not Sun's SPARC architecture, it's ARC International's ARC, the Argonaut RISC Core, which has its origins in (of all things) the Super Nintendo's SuperFX chip.
Some implementations it'll really screw up any RT plans you might have...
(From the excellent https://lkml.org/lkml/2011/5/25/228)
Most motherboard vendors also thrown stuff onto enterprise motherboards for doing things remotely. They can have issues: https://www.youtube.com/watch?v=GZeUntdObCA
Those core execute the codes from their local SRAM which can only be written to under very specific conditions. You can't arbitrarily write to their SRAMs.
An SOC has various bus arbitrators that are built into hardware which control the dataflow. It is part of the chip's backbone. I've never seen an architecture in which you could easily write to the aux core's SRAM. This is partially because those cores are often responsible for DRM therefore access to them is very restricted, but also because it is expensive (in terms of gates) and unnecessary to hang them off the main bus.
It is a very unlikely "DMA hacking" vector.
The peripheral can just as easily DMA to main memory and overwrite kernel code if the memory apertures are set wide open to allow peripheral to DMA anything into the host. Additionally unless you have PCIe or a similar bus with mastering capability a peripheral can't DMA.
Sounds good to me. I see UEFI as an added, redundant, poor quality OS. I'm a connoisseur of bootloaders and live in a TTY so UEFI is another command line that I do not need. You said it best: its features are "rarely used"; it just provides unwanted third parties with another "layer to hide in".
There are also a number of shortcuts for "shutdown is just two writes to a given register" that some OS probably expect to be around these days (a field in FADT) that I'm not sure how a complex ACPI shutdown routine would fare in practice.