On Windows, the window manager and GDI run in kernel mode inside win32k.sys. Why were they put there, and what does that design cost?

## Where graphics used to live Windows NT started as an unusually purist design for its era. The Win32 environment subsystem ran as a user-mode server process, and the window manager (USER: windows, messages, input) and the graphics device interface (GDI: drawing, fonts, device contexts) ran inside it. An application drawing a line or pumping a message sent a request to that server and waited for the reply. Architecturally this is exactly what you would want: a fault in the graphics stack takes down a user-mode server, not the kernel, and the subsystem boundary is real. Practically, on mid-1990s hardware, it was slow. Every GUI operation crossed a process boundary, with the context switches and copying that implies, and GUI operations are not rare — they happen thousands of times a second on a busy desktop. ## The NT 4.0 move NT 4.0 relocated USER and GDI into kernel mode in a module called `win32k.sys`. After the move, a drawing call from an application became a system call: `gdi32.dll` or `user32.dll` traps into the kernel, `win32k.sys` handles it, and control returns — no second process involved. `csrss.exe` remained for the parts of the subsystem that genuinely need a server (console handling, some process and shutdown bookkeeping), but the hot GUI path no longer touches it. This is the decision an interviewer wants you to be able to defend *and* criticise. It bought a large, measurable win at the time. It also permanently changed the security posture of Windows. ## What it costs **Attack surface.** `win32k.sys` adds its own large family of system services — a second dispatch table alongside the base one — covering window management, message handling, fonts and drawing. That code was written to be fast and, in its early years, was not written with hostile user-mode callers in mind. Any process that can create a window can reach it. Local privilege-escalation exploits against this surface have been a recurring theme in Windows security for two decades, and it is a standard sandbox-escape target: compromise a low-privilege renderer, then attack the kernel through the graphics call surface. **Blast radius.** Kernel-mode code shares the kernel address space. A memory-corrupting bug in the graphics path or in a kernel display driver is a bugcheck — the whole machine stops — rather than a crashed application. "The screen went blue when I plugged in the projector" is this design, visibly. **Servicing pressure.** Because it is kernel code reachable by everything, patches are urgent and generally require a reboot. ## How modern Windows mitigates it Microsoft never reversed the decision, but has spent years containing it: - **Splitting the module.** On Windows 10 and later the functionality is divided across `win32kbase.sys` and `win32kfull.sys`, with `win32k.sys` remaining as the entry module — which allowed editions without a full desktop to omit parts of it. - **Moving display drivers back out.** Under the Windows Display Driver Model a graphics vendor's driver is split into a user-mode component (the bulk of it, running inside the application's process) and a smaller kernel-mode component alongside the DirectX graphics kernel subsystem. When the user-mode part faults or the GPU stops responding, the system can reset and recover the display stack instead of bugchecking. That is why a modern GPU driver fault usually flickers the screen and logs a recovery. - **Blocking the surface for sandboxes.** A process can be created with a mitigation policy that disables win32k system calls entirely. Browser renderer processes use this: they render into shared memory and never call the graphics kernel surface, so an attacker who owns the renderer cannot pivot through it into the kernel. ## The interview point This is a rare case where an operating system publicly traded isolation for speed, and you can trace two decades of consequences from that one decision. A strong answer says what was bought (a process boundary removed from the hottest path on the machine), what it cost (kernel attack surface and bugcheck blast radius), and how the platform paid the cost down over time without being able to undo the original move. A weak answer treats it as trivia about a file name — or worse, claims GUI applications therefore run with kernel privileges. They do not; they call into kernel code exactly the way any other system call does.