[justinschuh]

So, the thing we call "win32k lockdown" on Chrome is just a term for the various things we had to do to enable ProcessSystemCallDisablePolicy on our sandboxed renderer processes (the processes that handle Web content). ProcessSystemCallDisablePolicy is a very big hammer, because enabling it prior to process launch means the kernel blocks all GDI and NTUser calls, such that the process can't interact with the UI or graphics subsystems. Chrome can do this because our UI and graphics acceleration layer is split into our unsandboxed browser process and the more weakly sandboxed GPU process.

The difference with Edge and IE is that they run their UI and graphics stack in their content processes, which are an analog to Chrome's renderer processes. However, any UI on Windows requires win32k kernel support, so they can't disable it like Chrome does. Instead, Edge uses its win32k filter to limit the attack surface to only the calls that they need. So, where Chrome's architecture allowed us to make an aggressive cut, Microsoft is instead working to iteratively shut off the same attack surface in Edge.

And yes, the win32k whitelist is currently restricted to EdgeHTML processes by the kernel and signature enforcement. I know this because we currently sandbox our GPU process at about the same level as an IE content process, and we wanted to use the win32k whitelist get the same improvements as Edge. Unfortunately, Microsoft is still working on the capability, and is not ready to expose it to third-parties yet (but has given signs they may be willing to do so in the future).

Source: I lead engineering on Chrome security and am the original architect of Chrome's win32k lockdown.