it would be really good if the people reverse engineering malicious software knew how computers worked:
"This Regin driver recurrently checks
that the current IRQL (Interrupt Request Level)
is set to PASSIVE_LEVEL using the KeGetCurrentIrql()
function in many parts of the code, probably in order
to operate as silently as possible and to prevent
possible IRQL confusion. This technique is another
example of the level of precaution the developers
took while designing this malware framework."
NTs driver model is a mixed model, many calls are chained from interrupts, others maybe are syscalls. Some driver functions like netfilters or filesystem filters may be called from both interrupts AND system calls.
Accessing some calls at the wrong irql is deadly. Similarly, if you are attached as a filter you can get tons of calls, most all of which are not relevant. You must be able to quickly filter those calls or the system can become unstable.
Admittedly, the efficiency of NT's design is pretty brilliant considering that we started with TSR interrupts in DOS, but it is also fraught with danger. For instance different locking calls can only be used at certain IRQLs, otherwise you can lock the entire system. Sometimes those calls only happen with certain configurations or kernel versions.
Being an NT driver developer is maddening. The Linux driver model is much better, as there are no mixed mode calls. Interrupts are chained but your function is always at the same or lower interrupt level. Most code is also explicitly kept out of interrupts, and instead operates as usermode syscalls. You can write an entire filesystem and likely never deal with interrupts.
