[eeeficus]

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?

[draugadrotten]

> you can disable the fix (via a special CPU instruction)

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.

[simias]

Nonsense, just make it so that only privileged kernel code can modify this configuration. Tons of CPU configuration parameters already work that way, it's a non-issue.

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.

[nolok]

Uh no, they would obviously make it so only kernel code can run that, like many other such settings.

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=...