摘要：作为全球用户量最高的消费级桌面操作系统，Windows 11虽存在一些问题，但仍是微软历代系统中体验最完善的版本——尽管部分争议性设计让许多用户选择长期坚守Windows 10。
作为全球用户量最高的消费级桌面操作系统，Windows 11虽存在一些问题，但仍是微软历代系统中体验最完善的版本——尽管部分争议性设计让许多用户选择长期坚守Windows 10。
不过，始终让用户困扰的一点，是微软长期推行的一项政策：操作系统加载驱动程序前，必须要求其经过数字签名。
简单来说，驱动程序是一种底层代码（通常运行在操作系统内核中），负责实现硬件或软件与Windows系统的交互。已签名驱动程序包含来自可信机构（如微软自身证书，或过去经微软授权的证书颁发机构）的加密签名，Windows会先验证该签名的真实性与完整性，再允许驱动程序运行。数十年间，这种驱动程序签名强制机制不断演进，如今已成为系统加载驱动的强制性守门员，且具有双重属性。
一方面，不可否认的是，它能大幅提升系统安全性，可阻止恶意软件在如此底层的级别运行（除非攻击者盗取合法证书）；但另一方面，它限制了用户对系统的控制权，要求用户必须遵守微软的规则。这种机制对用户自由存在一定排斥性，却又具备明确的安全优势：既是Windows最出色的安全功能之一，本质上却带有“反消费者”属性。
驱动程序签名是微软代码完整性（CodeIntegrity）安全功能的一部分，该功能最早在Windows Vista时代引入，到Windows 10 1607版本时正式成为强制要求。其核心逻辑很简单：任何运行在Windows内核（即“0环”，Ring0）中的代码，都必须携带来自可信机构的有效数字签名。根据微软官方文档，代码完整性通过“在驱动程序或系统文件加载到内存时验证其完整性”来提升操作系统安全性；而在64位Windows系统中，内核模式驱动程序必须经过数字签名。实际操作中，这意味着Windows会直接拒绝加载任何未使用认可证书签名的驱动程序。
与其他操作系统类似，Windows内核（ntoskernel.exe，即Windows NT内核）是系统核心，拥有最高权限，因此阻止未授权代码在此区域运行至关重要。数字签名的作用，就是确保驱动程序由可识别的开发者发布，且自发布后未被篡改。在默认策略下，未签名或被恶意修改的驱动程序根本无法安装——从安全角度看，这无疑是好事，既能保护普通消费者，也能保障企业用户的系统安全。
具体而言，正规硬件厂商与开发者需完成驱动程序的签名流程：在现代Windows系统中，这通常需要获取扩展验证证书（Extended Validation Certificate），并将驱动程序提交至微软审核。若某段代码试图在未通过该审核的情况下在内核中执行，系统会弹出类似“Windows无法验证此设备所需驱动程序的数字签名”的错误提示。这一机制可防范某类特定攻击——例如恶意软件通过安装根工具包（rootkit）或恶意驱动程序，获取对系统的完全控制权。在现代64位Windows系统中，加载设备驱动程序几乎是在内核中执行任意代码的唯一支持方式，而这一通道对未签名可执行文件完全关闭。
即便拥有管理员权限，也无法绕过这一限制：在64位Windows系统中，任何人都无法加载未签名驱动程序。唯一的绕过方式，是使用“禁用驱动程序签名强制（Disable driver signature enforcement）”启动选项（下次开机后会自动恢复默认设置），或通过bcdedit命令彻底关闭签名检查。这是微软设置的安全底线，即便电脑所有者也不建议突破。
微软推行强制驱动签名的进程，始于2006年——当时人们对间谍软件、根工具包及系统稳定性的担忧日益加剧。其实早在Windows 2000，驱动程序验证器（Driver Verifier）作为一款命令行工具问世，可用于测试驱动程序是否包含非法功能、检测漏洞；到Windows XP发布时，该工具新增了图形界面。彼时，驱动程序签名虽已存在，但并非严格强制——管理员可通过组策略设置，选择“完全禁止安装未签名驱动”“提示用户但仍允许安装”或“静默安装”。
这一局面随着64位Windows系统的普及被打破：从Windows Vista开始（甚至在Windows XP X64版本中就已有限制，不过当时用户可自签名证书），64位Windows系统正式要求内核模式驱动程序必须经过签名。这是微软更广泛安全举措的一部分，同期推出的还有内核补丁保护（Kernel Patch Protection，俗称Patch Guard）。Windows Vista X64版本强制驱动签名的政策在当时引发争议，但微软公开表示，此举旨在彻底消除某几类恶意软件，同时也是为了保护数字版权管理（DRM）机制。
驱动程序签名强制机制显然符合诸多行业利益，同时也意味着：当时微软实质上可强制企业“付费获取许可证”，否则其驱动程序将无法在大多数电脑上安装。此后，相关要求愈发严苛——正如前文所述，Windows 10 1607版本进一步规定，所有驱动程序必须经过微软认证签名（attestation signed）。
而Windows 11在新设备上默认要求UEFI安全启动（UEFI Secure Boot）和可信平台模块（TPM），进一步强化了对启动流程和驱动程序可信度的保障。本质上，现代Windows系统将哪些底层代码可运行的决策权集中到了微软（作为核心权威机构）手中。其结果是，攻击者更难突破系统防御；但与此同时，微软（及少数证书供应商）也成为了Windows平台的看门人。
尽管驱动签名机制已相当严格，但作弊程序供应商与恶意软件开发者仍在寻找漏洞，而这恰恰证明了该机制的有效性。一种常见手段被称为BYOVD（Bring Your Own Vulnerable Driver，自带漏洞驱动）：攻击者寻找已签名但存在已知安全漏洞的驱动程序，先让Windows加载这款合法驱动，再利用其漏洞在内核中执行恶意代码。例如，曾有攻击利用联想Mapper驱动，部署未签名的作弊驱动，并绕过Riot拳头游戏公司Vanguard反作弊系统的TPM检查。
这一问题还与直接内存访问（DMA）攻击和作弊程序密切相关：DMA允许硬件设备直接访问系统内存，绕过CPU控制，理论上可让另一台电脑读取或修改游戏内存数据。不过，Windows的内核DMA保护（Kernel DMA Protection）功能会利用IO MMU（输入输出内存管理单元）阻止未授权PCIe设备访问内存——只有配备DMA重映射兼容驱动程序的设备才能获得访问权限，而该驱动功能同样受微软签名机制保护。结合安全启动（可防止开机时恶意软件或作弊加载器在Windows启动前注入代码）与基于TPM的启动验证，即便在用户可控的个人电脑上，也能构建出安全性极高的运行环境。
这种攻击手段并非仅用于游戏作弊：多款勒索软件也曾利用驱动程序禁用系统安全功能，并将恶意代码加载到内核中——本质上是将攻击目标从操作系统层转移到微软已审核签名的底层代码层。恶意软件开发者需寄生在用户电脑已安装的合法驱动程序上，这意味着他们要么找到极常用驱动程序中的漏洞，要么诱骗用户安装包含漏洞的软件。
驱动程序签名强制机制只是整体安全架构的一环，单靠它无法防范所有攻击；但与微软其他安全技术结合后，其提升安全门槛的效果毋庸置疑。被盗的证书很快会被发现并吊销，硬件层面的绕过手段也往往难以持久。
核心矛盾在于：用户对自己的硬件能做什么、不能做什么，话语权被削弱。
若驱动签名机制仅对安全有益，为何会被认为“反消费者”？批评声主要源于：这种安全机制本质上限制了用户自由，削弱了用户对自有系统的控制权。安全与开放性之间存在天然的权衡，而微软明显更倾向于前者。在微软选择的模式下，操作系统仅信任经微软审核的底层代码——这种权限集中化不仅符合行业利益，还能让微软通过证书认证获利。
以禁用驱动签名验证为例：若用户想为个人使用开发自定义驱动程序（无论是适配自有硬件，还是现有硬件），操作会非常繁琐——要么每次开机时选择“禁用驱动程序签名强制”启动选项（会完全关闭完整性检查），要么启用“Windows测试签名模式”，两种方式均不便于日常使用。此时，用户对电脑的所有权已不再是传统意义上的“完全所有”：在内核层面，微软仍保留着控制权。
一方面，只有大型企业或资源充足的开发者才能轻松满足驱动签名要求：要为现代Windows系统开发“合规签名驱动”，开发者需获取EV代码签名证书（EV Code Signing Certificate）——这不仅需要通过严格的身份验证、配备硬件令牌，每年还需支付数百美元费用。知名文本编辑器Notepad++就曾因不愿向微软支付年度认证费用，导致其作为用户级程序却受签名政策影响，成为典型案例；驱动程序领域的情况同样如此。
另一方面，该要求还会导致普通用户无法使用未获得签名驱动更新的旧硬件。例如，若用户想将一款Windows XP时代的旧外设连接到Windows 11电脑，而该外设的驱动程序从未经过数字签名，系统会直接阻止其运行。用户要么禁用签名强制，并承担随之而来的安全风险，要么放弃使用这款硬件。过去，用户还能通过修改驱动程序解决问题，但如今受成本与复杂度限制，这类DIY方案已基本绝迹。
即便社区开发者主动尝试解决问题，也往往事与愿违。例如，曾有两款开发者常用的系统风扇控制驱动程序InpOut32和WinRing0：前者与Riot Vanguard反作弊系统冲突，因此多数开发者选择后者，WinRing0也成为Fan Control等工具的核心依赖。但2020年，人们发现WinRing0存在严重漏洞；几年后，Windows Defender将其标记为风险程序并拦截，导致依赖该驱动的应用彻底无法使用。
微软对驱动程序合规性的要求，还加剧了开发者的成本负担。由于WinRing0会在系统级安装，开发者意识到，软件运行依赖于用户系统中首次安装的WinRing0版本——这使得开发者很难验证其他应用是否安装了存在漏洞的版本，即便开发者竭尽全力，用户仍面临安全风险。这也是曾经Signal RGB开发团队最终决定自主研发RGB控制接口的原因：2023年，他们放弃WinRing0，转而采用自研的SMBus驱动。但开发者均承认，这是一项高成本投入：整个开发过程极具挑战性，需要投入大量工程资源。而小型开源项目既没有足够资金支持这种开发，也缺乏微软内核开发的专业经验。
如今，WinRing0的开发者OpenLibSys已基本停止更新；即便该驱动推出更新版本，在微软更严苛的审核标准下，也未必能通过签名认证。值得注意的是，微软其实知晓大量应用依赖WinRing0（如雷蛇Razer Synapse、赛睿Steel Series Engine等均曾使用该驱动），因此允许其多存活了几年，直至2025年才彻底封禁。
与Windows不同，Linux是一套开放系统：不存在决定内核可运行代码的单一权威机构。尽管Linux发行版也可启用“模块签名强制”（尤其是在开启安全启动时，部分发行版要求内核模块使用特定密钥签名），但最终用户仍可通过重新编译内核或关闭签名检查绕过限制。这也是反作弊软件无法在Linux上实现与Windows同等效果的重要原因之一。
在Linux系统中，拥有root权限的作弊者可掌控一切：他们可重新编译内核以移除反作弊钩子，或加载自定义内核模块——无需担心“集中签名机构”的拦截。此外，许多作弊者只需将作弊程序以root权限运行在/root目录下，就能规避检测；这也解释了为何游戏开发者不愿将反作弊软件移植到Linux平台。即便某款游戏强制要求root权限，用户仍可通过fakeroot环境让游戏“误以为获得root权限”，实则未赋予真正权限。
简言之，Linux的开放性意味着任何防御措施都可能被同等权限的攻击手段破解——这一特性也体现在当前Linux游戏生态中：尽管许多热门游戏可在Linux上运行，有时性能甚至优于Windows，但众多竞技类游戏仍明确拒绝支持Linux系统。这种逻辑同样适用于恶意软件，只不过Linux的恶意软件生态与Windows存在显著差异。
微软的驱动签名强制机制对企业颇具吸引力：通过锁定内核，Windows可实现在开放系统中无法达成的安全与控制级别。对许多游戏玩家与企业而言，这种安全与自由的权衡往往值得接受——即便它会让部分用户不满。而Linux用户虽享有极高控制权，但这种自由也意味着客户端反作弊机制基本失效；若想在Linux上实现与Windows同等的内核安全，最终仍需引入类似Windows的限制措施，而这恰恰违背了用户转向Linux的初衷。
值得一提的是，Linux用户无需集中证书机构也能保障安全，背后有多重原因：Linux先进的用户权限系统、开源社区对漏洞的快速修补，即便偶尔出现xz-utils这类重大漏洞，较低的市场份额使其对攻击者吸引力较低，以及软件主要通过已审核的仓库安装——这些因素共同作用，让Linux的安全性无需依赖“驱动签名”这类强制机制。
微软的驱动程序签名政策在安全性上的有效性毋庸置疑：通过要求所有内核驱动经过签名与审核，微软为消费级操作系统构建了防范底层恶意软件与作弊工具的强大防线。作为平台，Windows独特的优势在于能维持一个用户与软件均可信任的系统环境——这也是该机制成为最佳安全功能的原因：它切实有效，且为系统安全带来了显著提升。
但这种安全是以“牺牲消费者权益”为代价的：它将系统控制权从用户手中转移到集中权威机构（微软），而无法完全掌控操作系统功能的现状，让许多重视开放计算的用户难以接受。从某种意义上说，Windows 11将用户视为内核代码层面的不可信参与者——默认假设包括用户在内的任何人，若不加以限制，都可能做出有害行为。
从安全角度看，该机制是降低风险的典型案例：它大幅封堵了最危险的攻击路径；但从消费者权益角度看，用户仿佛只是租用硬件的使用权——因为能否使用某项功能，完全取决于微软的许可。试想，若这一逻辑进一步扩展到系统保护领域：若精简系统工具或自定义脚本的修改触怒微软，是否也会被禁止？
对普通用户而言，驱动签名强制机制无疑是有益的；但另一方面，开源开发者因开发与分享软件的成本过高而被排挤出平台，用户因无法完全掌控自有硬件而感到不满——这些问题，同样值得关注。
来源：简明科学指南
