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.
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.
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).
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.
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
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
-----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
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.