You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
One of our customers is expressing a requirement to run our software, which includes a MiniFilter, inside HyperV Windows Containers.
We produce a piece of software, one component of which is a minifilter that performs some I/O redirection. The minifilter virtually replaces certain executables with a proxy executable in a context-and-configuration-dependent way. Doing this in a driver has proven far more robust than trying to inject code into many userland processes, some of which reacted in fragile ways. Consistency of reads and executes can also be important in some cases: some software will open an executable, inspect it, and run it differently depending on what it finds (e.g., cygwin).
Upon attempting to start our minifilter driver (e.g., using sc start), I ran into exactly the same symptoms described at #268 . sc start promptly reports that the driver is stopped. There are no events created in the System event log. fltmc thinks fltmgr is not loaded, but sc query thinks it is. Reading between the lines of the reply to that issue, I am assuming there is some fundamental problem with using minifilters or fltmgr.sys from inside containers? I would understand why --isolation=process containers should be blocked from accessing fltmgr, but it isn't as obvious why this would be a problem for --isolation=hyperv, although I can imagine reasons if it isn't truly separate from the host.
Can someone knowledgeable about Windows Containers provide some background on what the underlying issue is?
Is there any hope of loading a minifilter into a hyperV container in the foreseeable future?
Is there a relationship between fltmgr on the host and inside a hyperV container?
I believe I/O performed inside a HyperV container bypasses minifilters on the host?
Any thoughts on what you would do in my shoes?
The text was updated successfully, but these errors were encountered:
Hi. Thanks for bringing up these questions. Long story short, you cannot install a minifilter in a hyper-v container. However, if you're not limited to a hyper-v container, and can use process-isolation instead, you can use a host process container (HPC) to install the minifilter. We are aware that people want to use their own filters in hyper-v containers but we don't have a timeline to share right now.
FYI @ntrappe-msft host process containers no longer work for filter drivers either since containerd 1.7 - see microsoft/hcsshim#1699 for more information as to why that doesn't work.
Currently if you want to use minifilters, your only option is to use host process containers on containerd 1.6.
One of our customers is expressing a requirement to run our software, which includes a MiniFilter, inside HyperV Windows Containers.
We produce a piece of software, one component of which is a minifilter that performs some I/O redirection. The minifilter virtually replaces certain executables with a proxy executable in a context-and-configuration-dependent way. Doing this in a driver has proven far more robust than trying to inject code into many userland processes, some of which reacted in fragile ways. Consistency of reads and executes can also be important in some cases: some software will open an executable, inspect it, and run it differently depending on what it finds (e.g., cygwin).
Upon attempting to start our minifilter driver (e.g., using sc start), I ran into exactly the same symptoms described at #268 . sc start promptly reports that the driver is stopped. There are no events created in the System event log. fltmc thinks fltmgr is not loaded, but sc query thinks it is. Reading between the lines of the reply to that issue, I am assuming there is some fundamental problem with using minifilters or fltmgr.sys from inside containers? I would understand why --isolation=process containers should be blocked from accessing fltmgr, but it isn't as obvious why this would be a problem for --isolation=hyperv, although I can imagine reasons if it isn't truly separate from the host.
The text was updated successfully, but these errors were encountered: