Olof,
Thank you so much for such a great, easy to use RAM disk. I have been recommending usage for years, but recently a question came up.
I am interested in learning a bit more about the security implications of using ImDisk.
Thanks for your kind words, I will try to answer your questions!
Specifically, we are currently utilizing some files that are encrypted at rest that we are mapping into shared memory space for accessibility by multiple processes.
If we were to opt to write these files into a RAM disk created with ImDisk, what is the data flow?
Is there any sort of caching used? If so, can you describe it a bit?
If you create an ImDisk virtual disk which is backed by virtual memory storage, all disk data is in a memory block allocated from virtual memory in the System process (process id 4). Virtual memory can physically be located in physical RAM (needs to be when used) or on disk in a system pagefile, such as C:\pagefile.sys. If you store security sensitive data on your virtual disk, this could be a scenario to take into account, because the disk data can be swapped out to physical disk at any time. To avoid this and make sure that the virtual disk data is stored in physical RAM at all times, you can use the awealloc driver. There are a few examples in this forum, for example in the FAQ.
ImDisk itself does not use any cache, except that data from last read or write request is held in a separate non-paged pool memory block, for faster I/O response. However, filesystem drivers, such as FAT or NTFS drivers, could use various kinds of caching internally, but that is out of scope for what ImDisk or other disk drivers are responsible for.
I noticed that when the kernel driver service and/or the helper service are stopped, I am still able to read/write/mount/dismount a drive.
If you stop the driver it will automatically be started when you request to create a new virtual disk.
The helper service is not used when you just use ImDisk for memory disks, like in your case. The helper service is only used for "proxy mode", when I/O requests are redirected to some other application, possibly across network.
I also used process monitor and process explorer to try to understand the i/o activity a bit better, but I did not see where the reads/writes are taking place.
It is difficult to follow I/O in that way. What you see in process monitor are file I/O records where applications requests read or write to individual files. Then, requests are handled by the filesystem driver and possibly carried out directly inside the filesystem cache. If disk I/O is required to carry out the request, you can use Disk Monitor or similar to follow when filesystem drivers request I/O to specific sectors on the disk drive. The driver for the disk drive is in this case ImDisk, which will just copy I/O buffers to or from the virtual memory where the virtual disk is stored.
The filesystem tasks are generally taking place in a thread in the calling application. The calls to the disk driver are generally not taking place in the context of the calling application though, but rather in some cache or lazy-write thread created by the filesystem driver. Such threads generally, but do not need to, run in the System process.
When the disk driver get an I/O request it queues this work to a worker thread. There is one worker thread for each virtual disk in ImDisk. Worker threads run in the System process. This makes it possible to carry out requests at a lower IRQ level but still in kernel mode, so that it can call things that are not safe to call at non-pageable IRQ levels.
When about IOCTL requests sent directly to the disk driver, using for example DeviceIoControl or similar API functions, the relevant handling functions in the driver usually run directly in the context of the caller. There is no other process or thread called in that case. A few IOCTL calls need to do a few things that needs to be done in the worker thread though. Such requests are queued in a way similar to read or write requests.
If you can cite specific functions in source code that handle the read/write operations, it would be great!
In sys\imdisk.c you have functions like ImDiskReadWrite and ImDiskDeviceControl which handles requests from applications and filesystem drivers. These functions carry out a few things directly within them, while most tasks are queued to the worker thread. The worker thread is a function called ImDiskDeviceThread.
I hope this answered some of your questions!