A story of three kernel vulnerabilities

If you're root you've also got access to the MMIO regions of a bunch of devices with DMA engines, so just locking down MSR access isn't going to be a huge win. The Secure Boot work covers most of this, but it's based on the assumption that unless you've got some mechanism for verifying the integrity of your bootloader and on-disk kernel, the security improvement isn't huge - modify the embedded sectors of the bootloader (so tripwire won't pick things up), and just wait for the system to be rebooted for a kernel security update.

Signed module support in RHEL was never about security, it was about supportability. If customers are willing to use MSR hacks to load unsigned modules they're also going to be willing to just modify their bug reports to remove the tainted flags, so making it foolproof was never a great concern.