Thomas Weidenmueller wrote:
Alex Ionescu wrote:
(To be honest, my original idea was to
use "nop" and overwrite it with "ret", but both Patrick (who wrote
the
patch) and MS were right in making it a "ret" by default and using
"nop"
to overwrite, since that's even faster).
I don't understand how a modified nop to a ret can be faster than a ret
generated at compile time, or vice versa. However, having a ret by
default makes more sense ;)
- Thomas
Simple:
If you have a "nop" by default, then your job is as follows:
- Detect support for the instruction
- If it's NOT supported, overwrite with ret.
Additionnally, the default state of the function is to WORK, which
fundamentally speaking is wrong because you're assuming that the
advanced functionality exists, and then you're disabling it. Since
you're trying to be safe, then the whole point is to protect from the
potential BSOD.
However, with a "ret" by default, you only overwrite with nop if the
instruction IS supported. Apart from the design issue itself, I think
the premise here is that more CPUs don't have the support for the
function, then the ones that do.
Best regards,
Alex Ionescu