More on NX Insanity

I'm gonna take the contrary view - you don't have the source code for Windows kernel functions, so you can't see the comments, and even if you did, you wouldn't be able to click links to internal tickets. These smell exactly like specific workarounds for specific real-world issues where, for whatever reason, the documentation doesn't match reality. I've written lots of code where I write a two-paragraph comment in front of a one-line hack explaining why I'm doing something weird for now and why we hope to be able to clean up the code in five years - and that's just for legacy internal services, not weird CPU bugs. If you don't have the backstory and you just have the disassembled code, of course it will be "not at all obvious what problem Microsoft was trying to solve."

A VMM on an NX-capable CPU that doesn't support NX doesn't seem like something that's worth MS supporting. I'm going to guess they talked about it internally, and decided that whatever they needed to fix was worth the tradeoff. Maybe there's one CPU where NX is in fact supported but for whatever reason it's missing in CPUID, and you've never seen that CPU. Also, honestly, a VMM that doesn't support NX sounds remarkably like malware, if you run into it in production and not on the system of a hobbyist writing their own VMM, and failing hard when you know the CPU you're on supports NX and you know that CPUID is lying to you is an entirely reasonable decision.

Similarly, re skipping force-enable on 32-bit SSE2 CPUs - there's probably one CPU where the force-enable codepath causes some subtle problems, and this is the fastest/easiest way to identify that CPU, and they're not terribly concerned about accidentally missing some other cases. And again, you neither have the comments nor the `git blame` (or whatever MS uses) of that code nor the internal trouble ticket where someone spent weeks chasing down an elusive CPU bug. Of course it makes no sense to you.

And if there is some real problem behind these two cases, it's hardly true that "the original issue is long gone" - Windows has very long support cycles. This isn't a "problem in the IT industry," it's the reality of the game. If you want your code to work on real-world machines and you want real-world customers to pay your real-world salary, you have to write code for the world as it actually is, not as you wish it would be.

NX=NoeXecute bit on memory page tables (according to the link in the article)

(I didn't know that, maybe it helps someone else)

Here's a related story on why Microsoft might not want to believe the result of a query of hardware capabilities:

https://devblogs.microsoft.com/oldnewthing/20040211-00/?p=40...

>In other words, whenever DirectX asked, “Can you do this?” they answered, “Sure, we do that,” without even checking what the question was.

> That’s right. If SSE2 is reported, KiTryForceEnableNx does nothing. How does that make sense? I don’t know. It is true that all AMD processors which have SSE2 also have NX (and it can’t be disabled). But all Intel Pentium 4 CPUs made before late 2004 (and some made after) have SSE2 yet no NX.

This is an odd choice, and from the sound of it -- they're only checking SSE2, assuming its presence means that NX can be enabled, enabling it and ... nasal demons of some kind.

I'm guessing someone didn't read the specs carefully enough on the Intel processor side, but at the end of the day it ended up being a "Won't Fix" simply because they explicitly list both SSE2 and NX as required[0].

It's not great to fail with what I assume is some error message that doesn't simply say "Your processor is not supported, see our 6-page requirements document online on another computer". It'd be ideal if the OS could accurately check its minimums.

I think of the application's I've built (nothing deployed widely), it's rare that I've had to do operating environment validation (the need for it in the applications I write is minimal beyond "can I allocate a little memory"), and from some brief reading, it sounds like there's a more than a few edge cases involved.

If my experience as a user (who buys AMD products, usually) is any indication ... No Man's Sky and a 3D program who's name escapes me both required SSSE3[1]. Both blew nasal demons.

[0] Section 3.1 https://docs.microsoft.com/en-us/previous-versions/windows/i...

[1] I seem to recall it was something like SSSE4.2 or some oddness, but I couldn't find a reference to it ... only SSSE3, which had the same problem of having an extra "S", confounding Google.

edit: and grammar and speling.

> But it’s causing trouble because if NX cannot be enabled on an Intel CPU for whatever reason (such as running in a VM on a host with disabled NX, thanks Intel!), Windows 10 doesn’t believe the CPUID information and tries to enable NX anyway, which blows up.

This seems like a "Doctor, it hurts when I do this." kind of thing. Just don't do that.

Is there any good reason to disable NX systemwide on a VM host? Seems kinda risky.

It seems like it shouldn’t be too difficult to just test if it works, if the processor says it does.