About MONITOR and MWAIT

[Luchezar_B_]

Hi, I wanted to ask why those 2 instructions should be privileged Unless I miss something, I can see no reason for that. The [only] purpose of those 2 instructions is to save power. They don't do anything that can have security consequences, and have no effect on the architectural state of the processor, whatsoever. Disallowing them for ring3 code only means that certain [spinlock] algorithms that run in user space can not be as power-efficient as in ring0. But isn't it in intel's best interest their processors to be as power-efficient as possible in all situations?

[James_C_Intel2]

Back when the instructions were introduced there were backwards compatibility issues that prevented them from being available in user space. (Some existing codes used those opcodes assuming that they would raise #UD, and would be broken if they didn't do that). That problem was fixed for the future by clarifying in the instruction set reference that unimplemented opcodes cannot be relied upon to stay unimplemented, and that it you want to raise the #UD exception you should use the UD2 instruction which is guaranteed to do that in perpetuity.

It's probably no use to you, but on KNL you can have monitor/mwait enabled in ring3 by writing to model specific registers. (See this discussion  or the latest Software Developers' Manual which now includes the MSR details too).

[Luchezar_B_]

I see, thank you for the detailed reply. So it is again a bag of stones from the history that is dragging us to the bottom. At least its nice to hear that for newer processors things are getting better, though it would probably take many years before it becomes something that we can rely on to be available, as with any new CPU feature