Embed Notice

@amy I learned that accidentally. I was discussing how to adopt a security feature in NT and someone on that team casually mentioned third-party drivers (including antivirus) running things in interrupt handlers. The more I learned, the more horrified I was. On FreeBSD and XNU, interrupt handlers do one thing: wake a thread (or some work-queue equivalent). The thread is then preemptive. A small number of things run with interrupts disabled but it’s very rare in drivers or subsystems outside the very core parts of the OS. In Windows, the driver model seems to encourage people to just do the real work in interrupt handlers. So your USB camera is stalling a core (and whatever thread is currently trying to run there) for ms at a time, and so are a load of other kernel things.

Even FreeRTOS discourages this kind of thing, and it’s designed for a use case where it isn’t a terrible idea.

In CHERIoT RTOS we formalise it and bind interrupts to futexes, so the only thing that happens in an interrupt handler is that one or more futexes get woken and then we may make a scheduling decision if any of the woken threads are higher priority than the one that woke (on our chips, we have designed the interrupt controller so that it can avoid raising an interrupt if it wouldn’t result in a scheduling decision).