違反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。在大多數情況下可以什麼都不是但在某些情況下可能是非常難以捉摸和研究的惡臭。