Blocking Legacy File System Filter Driver in Windows vNext

FYI - If you have a legacy file system filter driver, it can be blocked by using a reg key in upcoming Windows release for both Client and Server.

We recommend you to port your legacy file system filter driver to mini-filter driver as soon as possible. Please refer below link for more details.

https://msdn.microsoft.com/en-us/library/windows/hardware/mt712331(v=vs.85).aspx

Regards,
Bhanu

As I see it, this feature is to enable the computer Admin to block the running of legacy file system filters ( which I think is a good idea, don’t get me wrong), but what would stop a legacy filter to start during boot ( before SMSS.exe ) and also have a registry filter and return IoBlockLegacyFsFilters = 0 everytime this gets queried ?
So my question basically is, “Is this enough to block a legacy filter from loading ?” I’m just curious.


Gabriel Bercea
www.kasardia.com

In Windows vNext, the legacy file system filter will be blocked/unblocked based on the reg key value.

Post Windows vNext, the reg key will be removed and the legacy file system filter will be blocked by default. There won’t be any option to unblock legacy file system filter.

Regards,
Bhanu

>during boot ( before SMSS.exe )

Many registry values in this subtree are queried by kernel itself, not by SMSS at all.

Also, instead of implementing these hacks, it is better to rework the code to be a minifilter.


Maxim S. Shatskih
Microsoft MVP on File System And Storage
xxxxx@storagecraft.com
http://www.storagecraft.com

Given that Filter Manager is itself a legacy filter, there is clearly some mechanism for bypassing this. Whether or not it is *worth* bypassing is another question entirely. It’s been 12+ years since Filter Manager was first introduced, there’s no strong reason to avoid switching (other than the “if it isn’t broken, don’t fix it” model.)

The more interesting question is whether or not legacy filter drivers are the source of a disproportionate number of crashes (versus mini-filters).

Tony
OSR

Does this mean that Filter Manager will no longer be present?

Tony
OSR

I would say Msft knows how to differentiate between their filter manager and another filter. Probably functions like IoRegisterFsRegistrationChange will not be available/exported anymore and the minifilter will be notified another way. Nevertheless I believe that minifilters are the way to go, I was just curious with the initial question how was this going to be implemented.


Gabriel Bercea

Windows Kernel Driver Consulting

www.kasardia.com

On Fri, Apr 1, 2016 at 6:04 AM -0700, “Tony Mason” wrote:

Post Windows vNext, the reg key will be removed and the legacy file system filter will be blocked by default. There won’t be any option to unblock legacy file system filter.

Does this mean that Filter Manager will no longer be present?

Tony
OSR


NTFSD is sponsored by OSR

MONTHLY seminars on crash dump analysis, WDF, Windows internals and software drivers!
Details at

To unsubscribe, visit the List Server section of OSR Online at

Filter Manager is not going away. It will be the only legacy file system filter allowed to load post vNext.

Christian [MSFT]

Some people get to have all the fun.

Tony
OSR

> Probably functions like IoRegisterFsRegistrationChange will not be

available/exported anymore and the minifilter will be notified another
way.

Yea, but if I can’t see it FltMgr.sys cannot

I would say Msft knows how to differentiate between their filter manager
and another filter.

I’d hazard they’ll check a signature.

R

Nah, they’ll either use one of the secret APIs that FltMgr uses, or they’ll base it on load ordering + first caller wins.

I have an even better idea and I know for a fact msft has done it in the
past.
I don’t remember exactly for what driver ( I think something related to
portable devices ) you could not attach directly to it, BUT you could enable
verifier for it. So verifier would be the only allowed driver that could
attach device objects in that stack directly. So if you wanted to attach you
could have named your driver to Verifier and you would bypass it but that
would mean adios verifier.
So in this case I would assume all Msft file systems will allow only device
objects that have the driver objects name FltMgr. Problem solved :slight_smile:

Regards,
Gabriel.
www.kasardia.com

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@videotron.ca
Sent: Tuesday, 5 April, 2016 17:54
To: Windows File Systems Devs Interest List
Subject: RE:[ntfsd] Blocking Legacy File System Filter Driver in Windows
vNext

Nah, they’ll either use one of the secret APIs that FltMgr uses, or they’ll
base it on load ordering + first caller wins.


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:>

> So in this case I would assume all Msft file systems will allow only
device

objects that have the driver objects name FltMgr. Problem solved :slight_smile:

Continuing on speculations, Microsoft can as well use the same approach
Like they did with kernel debugger DLL - needs to be signed by some special
Kind of certificate, otherwise Windows refuses to load it. Problem solved.

L.