zlacker

SMM is used all the time:

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.

>>pgeorg+(OP)
> and simply rewrite those variables

Good luck trying that once that memory is encrypted with SGX.

>>pdkl95+X2
SGX is too complex for such purposes, and it also doesn't provide access levels to hardware.

The alternative to hooking into UEFI code would be to just write to flash by yourself. SMM has additional permissions there.

>>pgeorg+(OP)
Yeah, I was going to say, I've seen hardware were advertised features were implemented with SMM. You could possibly take it away but it sure does enable a lot of nice hardware fixes without re-spinning silicon.

Some implementations it'll really screw up any RT plans you might have...

>>pgeorg+(OP)
Couldn't those register writes required on shutdown be included in ACPI?

>>caf+oM
Since it's traversing the PCI bus hierarchy, not easily.

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.