Windows Kernel-Level global Critical Section

2
votes

I'm writing to a user-space buffer from a kernel-level driver (from the IOControl functionality) and I need to make sure the user-land program/service won't overwrite the buffer or read it before the driver has finished writing to it.

Is there a way (and if so, what is the preferred way) to enter a kind of 'global critical section' within a kernel-mode driver on Windows allowing a driver to obtain exclusivity for processing system-wide for a short time so that the driver can have guaranteed exclusive access to a buffer in user-space?

1
windowsdriverkernelcritical-sectionwdk
What do you want to achieve? There is no (exported) global lock in the windows kernel. You can easily use spin locks or mutexes/etc. in your kernel driver if you want that. - Christopher
Can you tell us the actual problem you are trying to solve? Is there a real-time requirement in your hardware? - Simon Richter
I'm writing to a buffer that is held in user-space from the driver (from the IOControl functionality) and I need to make sure the user-land program/service won't overwrite it or read it before the driver has finished writing to it. - Qix - MONICA WAS MISTREATED
Pass your buffer via IOCTL and complete IOCTL when the driver has written some data to it. Don't do complex locking if it is possible. - Sergey Podobry
Then you should make sure that the user-mode program does not modify the buffer rather than trying to lock processing system-wide. Look at the ioctl examples in the DDK for simple samples and read on User-Mode Interactions: Guidelines for Kernel-Mode Drivers or similar - msam

1 Answers

1
votes

Taking into account your reply in comments, one way to achieve that is to maintain kernel-mode threads affinitized to each system processor and raise their IRQL to DPC at the time when you write to the buffer. Thread scheduling is not allowed at DPC IRQL so the user-mode application won't be able to take control.

Note: this is the answer to the question, but basically I agree with the comments saying that you are not supposed to do that. You should probably redesign the driver so that it works under the assumption that user-mode buffer can change at any moment.