PMI handler and unloading of driver

Hi folks,

Im using sucessfully HalSetSystemInformation(HalProfileSourceInterruptHandler, …, …) for registering PMI interrupt handler. All works fine - no issues. When I need to stop handler, I’m using HalSetSysteminformation(HalProfileSourceInterruptHandler, …, nullptr) passing nullptr as callback function no issues here as well.
Question: As Im looking at OS code I see handler function pointer has no special code safety mechanism that would prevent my driver code beeing unloaded before any other CPU core would exit from interrupt handler. In other words: if CPU#1 is just handling interrupt in my routine and on CPU#2 I will call HalSetSystemInformation() to unregister code and immediately after that there would be unload of driver - isnt here a chance for bugcheck? And if so - is there option to graceful without issues unload such driver?


Yeah, the OS would typically use IPI callbacks to do this, are you sure it
isn’t? But you are off in undocumented hell. If in fact this is just
changing a single aligned 64bit value then it is atomic on x64 processors.
But there is still a window. You don’t have access to the IPI mechanism,
your other option is to set dpc interrupts on all processors and wait for
them all to rendezvous and then clobber the interrupt pointer.

Or put a delay in your unload.

Mark Roddy

Hadn’t ever played with this. Stepping through the function there does NOT appear to be anything to prevent your driver from unloading (there’s a lock to protect registering/unregistering the callback, but it’s not held around the call).

Doing a KeIpiGenericCall after you unregister would probably do the trick. Or just wait like Mark said (seriously bad luck to hit that window!)