2 ms·
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
by octoberfranklin 2mo ago
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.
In 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.
- userbinator 2mo agothe SMM code would have no reason to disallow the kernel modifying or replacing it Don'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".
- inigyou 2mo agoIt'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.