从 nv-uefi-unlocker 看启动时机与固件权限
一张 RTX 4060 Ti，同样的 165 W 设置，8192 阶矩阵测试的 FP16 吞吐从 46.78 提高到 75.28 TFLOPS，BF16 从 47.24 提高到 76.71 TFLOPS。同组 FP32 对照却基本不变。这是 nv-uefi-unlocker 仓库公开的一组前后对照，变化集中在特定的计算路径。[8]
让这组变化发生的程序，在 Windows 启动前运行。它需要先让 GPU 接受原厂签名固件，再利用固件处理外部数据时的缺陷获得写入机会，设置速度覆盖值，最后把设备交还驱动。这里的难点，远比向某个寄存器写入一个数字多。[5][6]
沿着这条过程往下看，才能理解三个问题：为什么选择驱动接管前，为什么原本写不进去的设置后来能写，以及写好的状态怎样留到应用真正开始计算。
下文以已有实机记录的 Ada 路径为主，源码基线为 51bc8b49，资料核验日期为 2026 年 10 月 28 日。性能数据来自项目与上游公开记录。
一 算力变化发生在具体的计算路径
GPU 里有不同的执行资源。Ada 的一个 SM 包含四个处理分区，其中既有常规 FP32、INT32 运算单元，也有面向矩阵乘加的 Tensor Core，以及调度器、寄存器和访存设施。它们承担的任务不同，吞吐统计的口径也不同。[2]
因此，文章里的精度名称也要跟着测试路径理解。矩阵运算可能采用较低精度的输入和较高精度的累加，而常规浮点运算又走另一套执行资源。把它们都缩写成一个“算力”数字，会掩盖真正改变的部分，也会让读者错误期待所有软件得到相同倍率。[12]
图 1｜按 NVIDIA Ada 白皮书简化绘制的 SM 功能分工。示意图省略部分模块，不表示物理版图，也不表示解锁增加了计算单元。[2]
一条计算路径最终有多快，取决于执行资源、时钟、每周期能够接收的工作，以及数据能否及时送到。频率只是其中一个因素。某类运算即使拥有硬件执行资源，也可能受到速度选择状态约束；覆盖这组状态，才有机会提高对应路径的有效吞吐。
这个项目沿用的社区研究，把目标称为 SM speed-select override。它调整 FEAT 特性覆盖块中的运行时状态。上游专门测试了 FP16、BF16 输入及 FP32 累加等 Tensor 路径；这里的“FP32 累加”，不能直接理解成普通 FP32 CUDA 核心算力。[12]
源码与实验支持“相关速率限制被覆盖”的解释，但尚不能直接展示限速在晶体管层面怎样实现。项目没有改变 SM 数量、显存容量或物理熔丝。因此，理解它时应把关注点放在可修改的运行状态，以及修改前后的实际运算行为上。[5][7]
二 UEFI 提供独占处理设备的窗口
仓库的入口是一个 UEFI 应用，产物名为 BOOTX64.EFI，可以从 U 盘启动。此时 NVIDIA 的操作系统驱动还没有接管显卡，UEFI Boot Services 仍可用。程序通过 PCI I/O 接口访问设备，完成事务后再链式启动 Windows Boot Manager。[1][5]
图 2｜依据 UEFI PI 1.8 Figure 2.1 与仓库入口重绘。工具是由启动选择运行的 EFI 应用，在操作系统驱动接管前工作。[3][5]
选择这个时机，可以避开驱动已经建立起来的复杂运行状态。程序会处理目标卡上的 GOP 图形输出与驱动占用，再独占设备。目标卡如果同时承担启动画面，过程中就可能暂时黑屏。画面是否还在，并不能证明固件操作是否成功。[5]
但“运行得更早”并不自动赋予 CPU 全部 GPU 权限。CPU 经 BAR0 访问显卡内部寄存器时，仍要遵守 GPU 自己的保护规则。即便主机已经能读到设备，也未必能修改受保护的速度设置。[5][13]
这意味着主机侧的控制权与显卡内部的权限不能直接画等号。UEFI 应用能够安排启动顺序、访问设备资源，但受保护寄存器依旧由 GPU 的规则把关。理解这层边界，才能看清后面的固件步骤为什么有必要：仅仅换一个更早的运行环境，还不足以完成目标写入。[5][13]
主板 Secure Boot 与 GPU 固件验签也分属两个层面：前者决定平台能否加载这个 EFI 应用，后者决定 GPU 内部哪些固件可以执行。启动窗口解决了时机与控制权问题，真正获得受保护寄存器的写入能力，还需要继续走 GPU 内部的固件链。
三 先让可信固件运行 再改变它处理输入的结果
GPU 内部也有负责管理的处理器。GSP 可以承担一部分原先由 CPU 侧驱动执行的初始化和管理工作，GSP-RM 是相应的资源管理固件环境。SEC2 则是内部安全处理器，承担 Booter 等固件的执行。[4][5]
这条链的大部分准备动作，发生在管理与安全处理器一侧。应用最后用到的计算吞吐，却体现在 SM 的执行路径上。两者通过受保护的配置寄存器联系起来：管理固件能够触及的控制状态，决定了计算单元随后如何工作。[5][7]
这次事务先要把它们的启动条件准备好。在 Ada 路径中，程序会尝试 SEC2 scrubber，处理有关引擎的状态；它随后读取目标卡 VBIOS 的 PROM 映射，解析 FWSEC，结合显存和保留区计算布局，通过固件建立受保护显存区域 WPR2。[5]
WPR2 本身是一块受保护的显存区域，不是用来永久保存这次解锁的闪存。FWSEC 与布局准备的作用，是满足 Booter 继续执行所需的前提。后续负责速度覆盖的是另一组寄存器；建立 WPR2，也不能单独作为算力状态已经改变的证明。[5][6]
这些准备有明确目的：让后续 Booter 看到它预期的区域和资源。WprMeta 就是交给 Booter 的元数据，说明镜像、签名数据在哪里，有多大，应当按什么布局处理。任何地址或大小对不上，都可能在触发漏洞之前被拒绝。
这里还有一个版本细节：当前实现允许 scrubber 尝试失败后继续，Turing 更是直接跳过这一步。因此，仓库概述中的链条需要结合架构与现行代码理解，不能把它画成所有显卡都必须成功通过的统一关卡。[5]
图 3｜Booter 镜像自身的签名，与它随后读取的外部签名数据，是两个不同对象。正常回放和解锁模式在输入处分支。[5][6][7]
最关键的区别，是这里存在两种“签名”。第一种属于 Booter 镜像本身。代码保留有效的原厂签名，让 GPU Boot ROM 能够验证它，并准许它进入固件执行环境。
第二种是 Booter 随后要读取的签名数据。WprMeta 指向一块独立缓冲区：正常回放模式里放原厂固件签名，解锁模式里则放 V67 构造的数据。被改变的是这份外部输入，Booter 镜像本身仍保留原厂签名。[5]
漏洞就在已经运行起来的 Booter 内部。它处理外部数据时存在无界复制，会破坏 DMEM 栈。构造的输入把固件已有的代码片段串接成 ROP 路径，借用当前固件的高权限上下文，完成受保护寄存器的改写。[5][7]
签名检查能够确认程序身份与完整性，却无法保证程序面对所有输入都没有内存安全缺陷。这个机制先满足原有信任链，再利用被信任代码内部的缺陷改变执行结果。它无须为一段任意新程序伪造 NVIDIA 签名。
当前源码根据有无 V67 选择一次 Booter 执行的输入。正常回放用于检查基础启动通路，带 payload 的模式执行解锁。历史记录里先验证正常启动、再验证载荷的开发过程，不代表工具每次都会连续运行这两轮。[5][6]
四 打开权限之后 再写入速度设置
保护这些设置的是 PLM，全称 Privilege Level Mask，即特权级掩码。它决定一组 GPU 寄存器允许哪些权限等级和访问来源读写。可以把 SS0/SS1 理解为屋里的控制旋钮，PLM 管的是谁能进屋调节。[6][13]
主机权限不够时，写操作可能直接被硬件忽略，程序表面上却没有明显报错。只有在高权限固件上下文中改写 PLM，主机后续的普通寄存器写入才可能生效。这是漏洞执行与速度设置之间的连接点。
这里还存在一层权限的间接关系：速度设置受 PLM 保护，而 PLM 自己也不是主机随时可以改写的普通开关。漏洞路径先让高权限固件改变访问规则，才把后续操作交回主机。这种安排把“如何获得一次有效写入”与“最终要设置哪些值”分开了。[5][13]
Ada 的 V67 链对四个 PLM 目标发起写入，但四个目标的验收值并不完全相同。当前代码明确区分了下面这些情况：[6][7]
WPR_CFG PLM 的目标和接受读回都是 0xfffff0ff；WPR PLM 与 FEAT PLM 接受 0xffffffff。FBPA PLM 虽然请求写入 0xffffffff，但当前逻辑接受 0xffffff0f 或 0xffffffff。[6][7]
例如，4060 Laptop 的公开报告中，FBPA 仍然读回 0xffffff0f，现行逻辑接受这一结果。所以，不能用“四个值全为 1”这种粗略规则判断成功，更不能把四次写入理解成四项都必定翻转。[6][9]
与速度覆盖直接相关的是 FEAT PLM。它打开后，主机再写入 SS0 = 0x88888888、SS1 = 0x00000008，并逐项读回。前一步获得修改资格，后一步才落实速度选择。看到 payload 执行标记，还不能跳过对 SS 值的检查。[5][6]
这些修改保存在易失的运行时状态中。程序读取 VBIOS 是为了提取启动材料，主链不把这次覆盖烧进显卡 BIOS，也不重写物理熔丝。断电或某些会重置相关状态的路径，仍会让覆盖失效，需要重新执行事务。[1]
五 从能改寄存器 到能把设备交还驱动
真正把方案做成可用仓库，还要解决许多启动环境差异。nv-uefi-unlocker 基于 gpu-unlock、gpu-unlock-ada、相关 CMP 解锁研究和 NVIDIA 开源驱动资料进行移植。它的重要工作，是让这些固件执行条件在 UEFI 中实际成立。[9]
资产管线同样是这部分工程的一环。项目从固定版本、固定哈希的公开输入生成对应材料，并核对产物，让参与复现的人使用一致的固件组合。哈希校验能够确认文件是否一致，至于这组材料能否适用于某张卡，仍要由设备识别、启动条件与实际读回来回答。[1][9]
Ada 开发报告记录过一个障碍：在对应 UEFI 环境里，Falcon 的固件装载 DMA 队列接受命令，却不消费。项目改用 IMEM/DMEM 的寄存器 portal 装载代码与数据，还纠正了地址编码和安全段放置方式。否则，日志里的“已装载”可能只是把错误内容放到了错误位置。[9]
不过，改用 portal 只解决了这部分装载问题。Booter 后续读取主机内存里的元数据、签名数据和镜像，仍然依赖 GPU 发起的 DMA。传输方向变了，对系统的要求也随之改变。
4060 Ti 的排障记录把这个差别展示得很清楚：CPU 已经可以访问显卡，Booter 却读不到正确的 WprMeta，返回 0x89。最终确认，上游 PCI 桥的 Bus Master Enable 没有启用，GPU 发出的主机内存访问被挡在路径上。[8][10]
修复代码沿 GPU 的上游桥路径启用必要的 BME，并读回确认，事务结束后再恢复原值。这个案例说明，CPU 到显卡的 MMIO 正常，并不能替代显卡到主机内存的 DMA 验证。早期把该个案归因于 IOMMU 的记录，也已被后来的根因报告更正。[10]
设置写进去之后，还要给驱动留下一张能够接管的卡。程序恢复签名元数据，处理固件临时状态、PCI 配置和图形输出，再启动操作系统。Ada 路径会执行 PCIe 功能级复位 FLR，并检查速度覆盖值是否仍然保留。[5][6]
FLR 作用于特定复位范围，不能当作整张卡断电。Ada 在已有实机中能够保留相关覆盖，因此可以借这个步骤清理部分启动状态；但这份经验不能直接照搬到另一代 GPU。
图 4｜权限打开、速度值存在、进入系统后有效，是三层证据。marker、寄存器读回和应用测试回答的问题各不相同。[5][6]
loader.log 的价值也在这里：marker 说明特定固件路径执行到了，PLM 读回说明权限状态符合预期，SS 读回说明目标值在那个时刻存在。交接取样和系统内验证，再回答这些值有没有穿过后续初始化。只看某一行成功日志，很容易把局部成功当成全部完成。
六 不同架构需要不同的成功判据
目前仓库为 Turing、Ampere、Ada 分别提供事务路径。它们共享“获取权限，再设置覆盖”的思路，但固件入口、寄存器地址、载荷行为和交接方式都存在差异。[5][6][7]
Ada 使用四目标 PLM 链与特定 marker，写 SS 后执行 FLR 并复查。Ampere 当前载荷主要打开 FEAT PLM，没有 Ada 那个 marker；代码把 PLM 从关闭到打开的变化作为执行判据。因此，两代不能套同一份日志模板。[6][7]
Turing 的 FEAT 块位于另一组地址。它先开 PLM，写 SS，再重新锁住 PLM；覆盖值可以留在锁住的门后。成功路径还要跳过 FLR，并配合适用的 Windows GSP 固件模式。这尤其能说明，“当前设置是什么”和“现在谁能修改它”是两种不同状态。[1][5]
兼容性也要分层看。代码识别一个 Device ID，只意味着会选择对应路径；一张卡完成读回和 Windows 交接，才是该平台上的链路证据；匹配的性能与正确性测试又是下一层。当前 3060 Ti LHR 已有读回与交接反馈，但它不能替所有 30 系保证收益。此版本也没有 Blackwell 与 GA100 的事务路径。[1]
七 性能收益最终由工作负载决定
回到开头的 RTX 4060 Ti。报告比较的是同一台机器、同一张卡、165 W 设置下的原厂冷态与完成解锁进入 Windows 后的测试。下面选取 N = 8192 的数据，保留报告自己的精度标签。[8]
图 5｜4060 Ti 公开对照：FP16 为 1.609 倍，BF16 为 1.624 倍，FP32 对照为 0.989 倍。图中倍率按两位小数显示。[8]
FP16、BF16 明显上升，FP32 对照基本持平，与“特定计算路径受到影响”相符。报告称 correctness 检查通过，同时明确没有完成长期负载稳定度、温度与功耗测量。因此，这组证据支持这次测试的收益，适用范围需要保持在相应条件内。[8]
另一份 4060 Laptop 报告里，FP16 GEMM 4096 从 29.89 提高到 49.02–49.33 TFLOPS，约为 1.65 倍。不同卡、矩阵尺寸与测试实现不能直接拼成同一条曲线；部分记录也未完整披露 API、computeType、mathMode 和实际 kernel，不能只凭精度标签补出不存在的细节。[9]
一个应用还包括数据搬运、缓存访问、调度和其他计算。假设其中 60% 的原始运行时间能获得两倍加速，剩下 40% 不变，总加速只有 1 ÷ (0.4 + 0.6 ÷ 2)，约 1.43 倍。这只是解释瓶颈的例子，并非本仓库实测。
上游也有实际边界：某组 RTX 4090 指令吞吐接近翻倍，匹配的 cuBLAS FP16 GEMM 却仅随形状获得 12%–34% 收益；另一项量化 MoE 工作负载没有提升。应用是否受益，取决于它是否卡在被修改的路径上，以及访存、功耗和散热是否成为新的限制。[12]
八 使用流程要围绕同一条证据链
实际使用时，先核对 Device ID、芯片家族、平台和已有实机记录，再用对应家族的 maker 脚本生成启动材料，按 README 准备 FAT32 介质和平台启动条件。Turing 还需要确认 GSP 固件模式实际生效。[1]
运行前留下原厂状态的同负载对照；运行后保存 loader.log，按本代架构检查 marker、PLM、SS 和交接状态；进入系统后，再做相同配置的性能与正确性测试。无 V67 的回放模式仍包含固件装载和设备状态写入，不能当作纯只读检查。
若日志通过、系统里却没有提升，应先检查覆盖是否丢失。相关电源域进入 D3cold、某些复位或驱动重新初始化，都可能改变易失状态，雷电 eGPU 也已有交接后失效反馈。不同平台不能仅凭同一症状确定相同根因。[1][11]
项目主链不刷写 VBIOS，但确实会改变 GPU 固件状态并执行设备复位。最终是否适合使用，需要由目标负载的正确性、稳定性与供电散热条件检验。额外叠加功耗墙或电压调整时，还应把这些变量与本工具自身的收益分开比较。
从一次权限突破 到一条可以检查的因果链
这个仓库能够工作，依赖一组相互衔接的条件：GPU 存在可覆盖的速率状态，特定签名固件提供了权限修改入口，UEFI 应用组织好执行环境，主机写入目标值，而架构专属的清理与交接让它有机会留到操作系统。
真正受这条路径限制的程序，才会把设置变化兑现成性能。读懂它的过程，也是把“启动成功”“写入成功”和“应用有效”逐一分开的过程。寄存器、日志、正确性检查和对照测试，合在一起才构成完整解释。
资料与图源
[2] NVIDIA Ada GPU Architecture 白皮书 Figure 5 第 11 页
[3] UEFI PI Specification 1.8 Figure 2.1 印刷页 II-9
[4] NVIDIA GSP Firmware 官方说明
[5] loader/src/tx.rs 事务组织与交接逻辑
[6] loader/src/tx_booter.rs Booter 执行与读回判据
[7] assets/src/payload.rs 各架构载荷目标
[8] RTX 4060 Ti 独立平台对照与原始日志报告
[9] RTX 4060 Laptop Ada 实测与移植报告
