4 ms·

no they don't, checking IRQL has nothing to do with "operating as silently as possible".

• throwawayaway 12y ago
  go on...
  • deleted 12y ago
    [deleted]
    • throwawayaway 12y ago
      so this could broadly be categorised as an innocent typo, they were in the right ballpark!
• kybernetyk 12y ago
  Well, if the system performance degrades because "sorry, we can't service the HDD because the malware driver comes first" then it's not really silent. A low handler priority makes sure that everything critical gets handled first and no one will get suspicious.
  • yuhong 12y ago
    I don't think that is the purpose of NT's IRQL though.
    • convivialdingo 12y ago
      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.