views:

100

answers:

1

I'm accessing my memory-mapped device via a device-specific physical memory on the PC. This is done using a driver that maps a specific physical address to a pointer in linear memory on my process address space.

I wanted to know if there is any way I can obtain a block the specific physical address and prevent other processes or devices from accessing this physical address?

The mapping of the physical address to linear one is done using a third party driver: TVicHW32.

EDIT: I can reproduce the scenario if I run 2 instances of my application with different flags. Both instances can access the same specific physical memory that is not a part of either process' memory space.

+2  A: 

Youd driver must do the job by exposing a service (DeviceIoContro) that checks if a range is already mapped, maps it if it's free, and records the reservation. Also a service thar frees the reserver area and unmap it. And of course you should free all the areas related to a particular handle on close. Unfortunately there is a slight asymmetry in the mapping/unmapping services, since the "mapping" service is done via DeviceIoControl, so it taked the handle obtained at CreateFile time, but the mapped area is not directly connected to the device handle anymore. Of course, you can arrange you driver's "close" method to automate the unmapping (ZwUnmapViewOfSection...).

Giuseppe Guerrini
My problem is that I don't control who access the physical address. I only control my process but apparently some other process or device driver access the same physical address.
Eldad
Oh, sorry. I didn't relise that you can't modify the driver. So things are much more difficult. A (small) hope is to prevento other users' process to access the device controlled by the driver by restricting the access to the public object exposed by the driver (i.e. the name you use in CreateFile to pen the device).
Giuseppe Guerrini
But this a very limited solution and not at all general. Anyway it can't prevent other DEVICE DRIVERS to alter erroneously the state of you device: a wrong kernel driver can do any kind of bad things :(Many years ago I encountred a similar problem while I was developing an ISA card: someone was writing on MY device. I had to connect the chip select signal to the CPU's NMI line, so when the card's memory was accessed I could intercept the NMI event with my low level debugger... Not at all easy.
Giuseppe Guerrini