How to ignore virtual volume devices?

NTDEV
1

Hi guys,

My filter driver attaches to the device stack for all volume devices. Anyway currently I’d like to somehow detect and ignore “virtual” volume devices, i.e. the corresponding drive of which is not physical. Consider TrueCrypt’s file hosted volumes as an example – a custom volume device, read/write to which actually goes from/to a file.

Currently I’d do something like sending a specific device i/o control and see if it’s handled properly. For example, still possible to analyze output from IOCTL_VOLUME_GET_VOLUME_DISK_EXTENTS to see whether valid extents are being returned.

Is there any standard approach for doing this?

2

> My filter driver attaches to the device stack for all volume devices. Anyway currently I’d like to

somehow detect and ignore “virtual” volume devices

If the emulation is really proper - then it is impossible.

For instance, I expect this to be impossible for properly written virtual storport miniport.

I would just drop such a feature from the product. It is evil anyway, since it limits the user’s freedom - what if he wants to filter the virtual disks?

–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com

3

Thanks for your reply, Maxim.

Well actually it’s not a feature, it’s an attempt to properly coexist with other encryption filters. All those virtual volumes doesn’t return anything on IOCTL_VOLUME_GET_VOLUME_DISK_EXTENTS, on which my filter relies. So, this seemed to be a sane check for drive’s “physical-ness”, anyway I’m afraid there may be, as you say, some proper emulations, for which I may end up with double encryption (and this is only in my filter) – one for virtual volume and the other for physical volume to which the former eventually redirects stuff, which seems inadmissible to me.

Thanks again for the reply, at least now I know it’s not something straightforward.

4

Just putting on my user hat here for a second, if I enable volume encryption
for a virtual volume that’s really a file on some underlying file system
(like a .vhd), I might expect the virtual volume to STILL be encrypted if I
move it’s physical storage elsewhere. If the underlying file is encrypted by
its parent volume, that’s perhaps not optimal performance wise, but is
exactly what I told the system to do. Double encryption might be a feature,
and expected behavior, not a bug. I assume if I enable NTFS file encryption
on a BitLocker encrypted volume, things will be double encrypted. If I
enable NTFS encryption on a file on a virtual volume that’s a file on a
BitLocker encrypted volume, I also will get double encryption.

Jan

Well actually it’s not a feature, it’s an attempt to properly coexist
with other encryption filters. All those virtual volumes doesn’t return
anything on IOCTL_VOLUME_GET_VOLUME_DISK_EXTENTS, on which my filter
relies. So, this seemed to be a sane check for drive’s “physical-ness”,
anyway I’m afraid there may be, as you say, some proper emulations, for
which I may end up with double encryption (and this is only in my
filter) – one for virtual volume and the other for physical volume to
which the former eventually redirects stuff, which seems inadmissible
to me.

5

>All those virtual volumes doesn’t return anything on >IOCTL_VOLUME_GET_VOLUME_DISK_EXTENTS, on which my filter relies.
I think you just get not proper implementation either of virtual disk/volume or a disk class driver, which a virtual storage driver used. You should simple test existing volumes on capability which you want to use.

Igor Sharovar

6

I totally agree, Jan. My example was a bit different. Suppose we have a virtual file hosted volume F: created, say, by TrueCrypt, and the host file resides on a disk drive C:. Currently my filter attaches to both devices – virtual volume and disk volume. Now if we encrypt C: and F: using my product, you get the following when you write something into drive F:. It is being encrypted by TrueCrypt, then it goes through my filter for F: and is encrypted again. Then (having in mind this is a file hosted volume) things are being written into the host file, which will result in encryption one more time, as drive C: is filtered as well. So, you get triple encryption, 2 of which happens in my filter, which is not what I’d like to see.

Thanks, Igor. Yeah, this is the approach I’m gonna use. Well, actually it’s by no means a virtual storage driver. Say, TrueCrypt’s filter creates such devices for file hosted drives, and it just returns STATUS_INVALID_DEVICE_REQUEST as a response to IOCTL_VOLUME_GET_VOLUME_DISK_EXTENTS, which is entirely sane, as it’s actually not a physical drive.