Re[2]: problem with cache in a swapbuffer example(2)

I think you are talking about trying to protect data when your filter
driver is unloaded. That said, don’t indicate an unload routine in your
registration context. Of course there ware ways around accessing the
encrypted data on the disk but it is encrypted, which is the whole
point.

Am I missing something in your description of the problem?

Pete


Kernel Drivers
Windows File System and Device Driver Consulting
www.KernelDrivers.com http:</http:>
866.263.9295

------ Original Message ------
From: xxxxx@yahoo.com
To: “Windows File Systems Devs Interest List”
Sent: 6/11/2016 12:13:37 AM
Subject: RE:[ntfsd] problem with cache in a swapbuffer example(2)

>Peter, Is there any flawless way to protect a filter from unloading? It
>should protect the filter from unloading at all conditions unless it
>won’t suit my need.
>
>
>—
>NTFSD is sponsored by OSR
>
>
>MONTHLY seminars on crash dump analysis, WDF, Windows internals and
>software drivers!
>Details at http:
>
>To unsubscribe, visit the List Server section of OSR Online at
>http:</http:></http:>

@peter,
Thanks for the point on not supporting an unload pointer. It prevents unloading minifilter and prevents uninstalling it while being loaded as well.
I also found out that I can prevent manual detach by passing a NULL pointer as instance query tear down function.

The important question is:

Is there any way to force unload-detach-uninstall-stop or anything that can stop the filter from controlling a specific volume? I don’t mind if one can prevent filter loading or attachment. but I want them to be unable to stop a loaded and attached filter.
Am I safe now?

I use a stream cipher algorithm. There will be no block size or padding problem. I think all of this is out of my concern.

Yes, I have already seen that. It would be an effective utilization of slack space:) Especially, the storage controllers always do io in using LBA.

Adam