违反ZwOpenKey函数的潜在影响应仅在IRQL = PASSIVE_LEVEL

Question

第三方数据丢失防护驱动程序时，将启用驱动程序验证基于IrqlZwPassive规则

崩溃，包括以下信息调用它会导致驱动程序验证程序检测错误：

ZwOpenKey只能在IRQL = PASSIVE_LEVEL时调用。

如果在IRQL = PASSIVE_LEVEL之外使用ZwOpenKey，那么对Windows系统有哪些潜在影响？

这是一个严重的问题，我们应该向供应商提出，或者只在某些情况下。

Answer 1

内核中的所有Zw api只能在PASSIVE_LEVEL上调用。这是设计。如果打电话给APC_LEVEL这已经会是UB有时这可以工作，有时会产生挂起或崩溃。说ZwOpenKey - 注册表管理器可以从磁盘读取密钥数据，如果它仍然不在内存中。所以将IRP传递给文件系统并等待它完成。但是完成Irp可以在调用线程中插入特殊的APC（IopCompleteRequest）。如果线程在APC级别 - APC将不会被执行，直到线程的IRQL不低于被动。但它从来没有完成 - 他等待IRP完成..

另一点 - 退出Zw服务，系统检查 - 是在线程UserApcPending如果是，将IRQL提高到APC_LEVEL，启动用户apc，并降低回到PASSIVE_LEVEL（系统假定Zw呼叫PASSIVE_LEVEL） - 所以你可以在APC_LEVEL输入Zw api，然后在PASSIVE_LEVEL退出。可以问 - 为什么线程在某个时候有APC_LEVEL？简单地说，因为没有做IRQL提出？或存在一些要求，为什么在某些时候必须是APC_LEVEL？如果是的话，如果情况需要停留在APC_LEVEL，但提前线程将IRQL降低到PASSIVE_LEVEL，情况如何？真的是UB。在大多数情况下可以什么都不是但在某些情况下可能是非常难以捉摸和研究的恶臭。