Why not the other way around? You have the fix enabled and if you don't know you get protected by default. If you really know better then you can disable the fix (via a special CPU instruction), because you know you're not running anything critical?
The CPU can not be allowed to disable the fix, because then that could be done by an attacker. Therefore the only more secure way is to move in the secure direction, from insecure to more secure.
If for some reason you even want to forbid even privileged code from modifying the config then add an other "lock" bit that forbids subsequent reconfiguration till the next reboot.
And if an attacker can run code at the kernel level it's a non issue, as they're already on the other side of the airtight hatchway anyway [1]: they're in control of the computer and the memory.
[1]: https://blogs.msdn.microsoft.com/oldnewthing/20060508-22/?p=...