新的1-bit exploit“所有”Windows版本使用处理滚动条的内核代码中的错误。这让我思考。为什么Windows在内核中处理滚动条而不是用户模式？历史原因？有没有其他操作系统这样做？
答案 0 :(得分：7)
TL; DR：微软牺牲了性能安全性。
Scrollbars在Windows上有点特殊。大多数滚动条不是真正的窗口，而是在“父”窗口中实现为decorations。这引出了一个更普遍的问题;为什么Windows在Windows上以内核模式实现？
让我们看看替代方案：
替代方案1在处理您自己的窗口时具有很大优势;没有上下文切换/内核转换。问题当然是来自不同进程的窗口存在于同一个屏幕上，并且有人必须负责决定哪个窗口处于活动状态并在用户切换到不同窗口时协调更改。这个人必须是一个特殊的系统进程或内核，因为这些信息不能是每个进程，它必须存储在全局的某个地方。这种双重信息设计将变得复杂，因为全局窗口管理器不能信任每进程信息。我相信这个理论设计还有很多其他的缺点，但我不会在这里花更多的时间。
Windows NT 3实现了替代方案2的变体。窗口管理器在NT 4中被移动到内核模式，主要用于performance reasons：
...窗口管理器（USER）和图形设备接口（GDI）具有 已从Win32子系统移动到Windows NT Executive。 Win32的 用户模式设备驱动程序，包括图形显示和打印机 司机，也被搬到了行政区。这些变化是 旨在简化图形处理，减少内存需求， 并提高绩效。
......在同一份文件中还有更多技术细节和理由：
首次设计Windows NT时，Win32环境子系统 被设计为支持环境子系统的同行 MS-DOS，POSIX和OS / 2中的应用程序。但是，应用程序和 使用图形，窗口和消息传递所需的其他子系统 Win32子系统中的函数。避免重复这些 函数，Win32子系统用作图形服务器 功能到所有子系统。
此设计适用于Windows NT 3.5和3.51，但它 低估了图形调用的数量和频率。有 在单独的功能中作为消息和窗口控制的基本功能 进程从客户端/服务器产生大量内存开销 消息传递，数据收集和管理多个线程。它 还需要多个上下文切换，这些切换消耗CPU周期 以及记忆。图形量支持每秒调用 降低了系统的性能。很明显，重新设计 Windows NT 4.0中的这个方面可以回收这些浪费的系统 资源和提高绩效。
其他子系统现在并不相关，但性能问题仍然存在。
如果我们查看一个像IsWindowVisible这样的简单函数，那么当窗口管理器处于内核模式时，就没有很多开销：该函数将在用户模式下执行几条指令，然后将CPU切换到ring 0在内核模式下执行整个操作（验证传入的窗口句柄，如果有效，检索可见属性）。然后它切换回用户模式，就是它。
如果窗口管理器位于另一个进程中，那么你至少会将内核转换量增加一倍，并且必须以某种方式将函数输入和输出传递给窗口管理器进程，并且必须以某种方式导致窗口管理器进程执行等你的结果。 NT 3通过使用共享内存LPC和称为成对线程的模糊功能的组合来实现此目的。