
More on NX Insanity - eaguyhn
http://www.os2museum.com/wp/more-on-nx-insanity/
======
geofft
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.

~~~
saagarjha
And the counterpoint: sometimes you do get to look at the secret sauce and
find out that decision you thought was carefully considered is actually just a
poorly engineered workaround annotated with the equivalent of a shoulder shrug
and "we needed to ship and nobody has complained loudly enough for us to
revisit it".

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

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

~~~
gefh
Thank you!

------
minikites
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...](https://devblogs.microsoft.com/oldnewthing/20040211-00/?p=40663)

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

~~~
JacksonGariety
That's a good quote; but I think that the crucial sentence is this one:

> The driver must have been written by the sales department.

------
mdip
> 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...](https://docs.microsoft.com/en-us/previous-
versions/windows/it-
pro/windows-8.1-and-8/dn482072\(v=win.10\)?redirectedfrom=MSDN)

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

------
microcolonel
> _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.

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

