Find a solution to prevent post-May 2018 updates being offered on non-SSE2/NX machines

[kirb]

As seen in #67 and #86, enabling POSReady updates on an XP machine whose CPU doesn't have SSE2 or NX support will cause the SSE2/NX-only updates to be installed anyway. SSE2/NX instructions were first implemented in Pentium 4/Pentium M and Athlon 64. So far from those issue threads we've seen it manifest as IE8 crashing in module gdiplus.dll.

At first I assumed dropping non-SSE2/NX was an intentional decision on Microsoft's part, but now I start to wonder if it was actually a configuration mistake on their build servers that they decided to just roll with instead of fixing. Or, perhaps a lazy consolidation of build configs for XP - 7 era software onto the same build configs used for 8 - 10 (SSE2/NX became mandatory with 8) hoping not many people would notice or care. I haven't looked thoroughly, but I don't see any Windows Update detectoid for SSE2 or NX. That really feels like something they would check... I see no reason why they would suddenly decide to start bricking working, supported systems through minor security updates.

It's not like users have been running on a configuration that was never supported either, this seems to affect at minimum POSReady 2009, Office 2010, and Windows 7, the latter two being fully supported at the time these SSE2-only updates started coming out. As much as it would be kinda brutal to be running Windows 7 or Office 2010 on a Pentium III or Athlon XP, or god forbid a K6-II, that was completely supported by Microsoft. Nowhere in the Windows 7 or Office 2010 system requirements can a CPU featureset requirement be found. The closest I've seen to an official acknowledgement so far is a "known issue" in the Windows 7 May 2018 rollup that if you get a bluescreen on a non-SSE2 machine, you should upgrade to an SSE2 machine (:woman_facepalming:).

edit: The best explanation I found was that it might be related to Spectre/Meltdown mitigations. Apparently a fix was temporarily planned before Microsoft changed their minds. Still no explanation of why these updates needed to be forced onto computers that wouldn't be able to support them. I'm certain users of old PCs would be understanding that they don't get all of the mitigations (not that I think CPUs that old even needed them?).

So at this point the only thing I think we can really do is modify proxied responses on the server to create an SSE2/NX detectoid update, and then manually inject that prerequisite for all updates released in May 2018 or later. This would necessitate proxying Windows 7 through Legacy Update if the machine is detected as not supporting SSE2/NX. That's far easier said than done though, because the proxy currently has next to no understanding of the protocol requests/responses.

[MattTheTekie]

Thank you for putting this much commitment into the project. I hope this can be achieved down the line. It seems like a bit of a task with reverse engineering the protocol on its own, and let alone everything else. Keep up the work. ^_^

[Kichura]

Have looked into this a bit more and it seems to affect KB4088878 aswell meanwhile KB4075211 is safe to deploy to Non-SSE2 machines. So yes, This definitely seems to be Spectre/Meltdown related in terms of mitigating legacy CPU-related issues.

However one thing i have yet to find out is if it is even possible to deploy the affected update and above on non-SSE2 machines using some kind of workaround without causing system crashes or similar as result.

[CHA0SHACKER]

I gave @kirb a list of safe updates in in discord. But he has to work out how to filter them on non-supported systems first. Stay tuned.