I disagree. If it were not user hostile the days before BIOSes were cryptographically signed the SMM code would have no reason to disallow the kernel modifying or replacing it. Like `insmod` lets root-in-userspace modify kernel-privilege-level code.
replyIn fact the whole situation is very much analogous to Kernel Lockdown, which is controversial.
With signed bootcode you can give a reason for not letting the userspace modify the SMM code. But when all this stuff was designed there were no bootcode signatures.
It's like that for reliability and compatibility. The kernel on a 386 wants to stomp over everything, so if we want the kernel to not stomp on something we'd better hide it.
replythe SMM code would have no reason to disallow the kernel modifying or replacing it
replyDon't forget that SMM code started out in A0000 --- the area of RAM that would've otherwise been inaccessible and wasted anyway, because it was usually decoded to the VGA. Also, this was the era of DOS; there was no difference between "kernel" and "application".