3

From msdn:

Drivers that run in kernel mode must be very careful about directly reading from or writing to addresses in user space. This scenario illustrates why.

  1. A user-mode program initiates a request to read some data from a device. The program supplies the starting address of a buffer to receive the data.
  2. A device driver routine, running in kernel mode, starts the read operation and returns control to its caller.
  3. Later the device interrupts whatever thread is currently running to say that the read operation is complete. The interrupt is handled by kernel-mode driver routines running on this arbitrary thread, which belongs to an arbitrary process.
  4. At this point, the driver must not write the data to the starting address that the user-mode program supplied in Step 1. This address is in the virtual address space of the process that initiated the request, which is most likely not the same as the current process.

Can anybody explain this in other words? Points 2, 3, 4 are not very clear. Thanks.

Community
  • 1
  • 1
Nusrat Nuriyev
  • 1,134
  • 2
  • 13
  • 29

1 Answers1

0

Each process has its own "context" of execution which includes Data structures (page tables) used in Virtual to Physical address translation.

At any point of time, Virtual Address to Physical address mapping depends on the currently executing process at that time.

Take the following scenario :

  1. A user-mode program (say "Process-A" with a single thread) initiates a read request and passes a User-space buffer address.

  2. This read request reaches to Device Driver routine, which is running in Kernel mode. Now most likely, the actual read operation from Device hardware will take some time to complete. In this case, the Driver routine may not wait for the completion of operation. Instead, it will just start the read operation from the Device, and return immedietly. In this activity, the Operating System will also get notified that the read opeartion has started but not completed yet. The OS will put the Process-A in waiting state, and schedule some other Process (thread) in execution.

  3. Later when the Device completes the reading operation, it will raise an Interrupt to notify this. At this time, any arbitrary process (say "Process-B") will be in execution. That is the Page tables will be reflecting Virtual to Physical address space mapping for Process-B. The Driver routine called for servicing this interrupt will be running in Context of Process-B.

  4. At this point, accessing the virtual address provided by user-mode program at step-1 will access the Virtual Address corresponding to Process-B and not that of Process-A.

See the "Methods for Accessing Data Buffers" for different approches to transfer data to user-space from Kernel-mode routines.

Aftab
  • 53
  • 5