In theory, they've always banned JIT in UWP apps, at least by default. UWP apps can't use VirtualProtect; they have to use VirtualProtectFromApp, which only allows JIT if you have the "codeGeneration" capability (and always enforces W^X). I don't use Windows so I don't know how it interacts with this new thing. Maybe the protection wasn't enforced at the kernel level?

On any platform, it makes sense to enforce code signing by default as a hardening measure, but some apps like browsers cannot operate without a JIT. So there needs to be some exception process - possibly requiring the use of a separate process for JIT compilation, as Edge now does. You don't want to end up like iOS where Safari is the only browser permitted on the platform.

Modern apps completely banned JIT back in the Windows 8.x days (except for the CLR which was whitelisted), the APIs/capabilities you mentioned were only added in Windows 10.

> Microsoft should apply these same restrictions to all UWP apps. Yes, that means banning JIT compilation, as Apple does on iOS.

I really wish they didn't. Banning JIT means banning alternative web browsers (with alternative JavaScript engines,) banning other languages that use a runtime with a JIT, and making it very difficult to write programs that need a JIT for performance, like video game emulators. Banning JIT outright like Apple does makes for a less useful computing platform. What's worse is that if certain operating-system components are allowed to break the rules (like the built-in JavaScript engine,) it locks you in to the vendor's implementation of these components. Imagine if you could only use the CLR and not the JVM on Windows. Mitigating RCEs is important, but it's not that important.

Making it a policy that can be enabled per-app (like Windows 10, according to a sibling comment) is fine though.

UWP apps from the Windows Store already ban JIT compilation - at least for .NET apps.

When .NET UWP applications are uploaded the store pre-compiles them on the server with .NET Native. The user only downloads and executes native code.

Not really, the .NET Native step is performed at build time, the packages the developer uploads to the Store are AOT-compiled

You can .NET Native on your own machine for testing but the package uploaded to the store contains MSIL. The final .NET Native version is then compiled in the cloud.

https://blogs.windows.com/buildingapps/2015/08/20/net-native...

One great feature of .NET Native is that the compiler is capable of being hosted in the cloud. When you build your Store package in Visual Studio, two packages are created – one .appxupload and one “test” .appx for sideloading. The .appxupload contains the MSIL binaries as well as an explicit reference to the version of the .NET Native toolchain your app consumes (referenced in the AppxManifest.xml). This package then goes to the Store and is compiled using the exact same version of the .NET Native toolchain. Since the compiler is cloud hosted, it can be iterated to fix bugs without you having to recompile your app locally.

Sure, it does sound interesting. Now what about all EMET mitigations that Microsoft is deprecating by saying Windows 10 is "secure enough" as is?

Most of them are just built into Windows now and are accessible through both the registry[1] and at runtime[2][3]. The latter requires recompiling with source code changes but the former can be applied to any application.

The EMET mitigations which are no longer supported have either been depreciated because of better ones (control flow guard) or are not terribly effective (EAF/EAF+, use of debug registers).

[1] https://theryuu.github.io/ifeo-mitigationoptions.txt

[2] https://msdn.microsoft.com/en-us/library/windows/desktop/ms6...

[3] https://msdn.microsoft.com/en-us/library/windows/desktop/hh7...

I get your point, but most does not mean all, and hardening is all about adding layers. https://insights.sei.cmu.edu/cert/2016/11/windows-10-cannot-... is a complete review of the mitigations we are loosing.