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