Topic : Calling Ring 3 From FSD Or IFS Hook Causes Ring 3 To Hang Last Updated: January 20, 1998 Location : ====================================================================== Date: Tue, 20 Jan 1998 19:26:33 -0600 Reply-To: Windows and Windows NT Device Driver Development Sender: Windows and Windows NT Device Driver Development From: "Jeffrey M. Goodwin" Subject: Re: 9X: Blocking and deferrning IFSFN_READ/WRITE To: DDK-L@PEACH.EASE.LSOFT.COM Now that the can of worms is open, let me shed a little light. First I spent 2 months working 12 hour days corresponding with Mark Chamberlin at MS, and Stan Mitchell by email getting what your trying to do to work at an alpha level, and then at a product level with MS office. If you don't need to do data expansion, then you don't need to block or defer the i/o requests from IFSMGR. Presumably if you need data expansion, your doing encryption which was what I did. So, I'm assuming you need data expansion. The first thing to abstract from this process, is that IFSMGR and your hook driver, are both VFAT clients, contending for access to the same file so you do need to modify the sharing flags to get initial access, but you must be careful when you do so or for example MSOFFICE won't work... So, since you have two components contending for the same resource you need a mechansim to defer processing of IFSMGR, and then complete the request when your hook driver does it's business. There are asyncronous services documented in the DDK specifically for IFS, but they don't work as advertised, so you'll need to use RAW VMM services. Now, since your introducing your own syncronization primitives, into a system which wasn't designed to handle it, you'll have to compensate by handling the file locking, read, write, seek, open, and close functions properly. What you may not know, is that there are special undocumented flags which do special case operations to VFAT, so you'll need to reverse engineer these flags under every possible condition with MSOFFICE for example, to study the behaviour of how they affect your imposed data expansion manipulation. Special closes that don't close, special reads that don't read, special seeks that don't seek, etc..., but have special meanings. File size is another gotcha... In short, you'll need to trick IFSMGR into thinking that no data expansion is occuring, while forcing VFAT to allow it. This doesn't mention all of the snags you'll need to deal with , but the bulk of them. If you want to save yourself some time to market (and a few gray hairs), please feel free to contact us regarding licensing source code for what we have already. It's very well documented, and will save your company a lot of time and money. Sincerely, Jeffrey Goodwin President/CEO Ashely Laurent, Inc. www.osgroup.com ====================================================================== From: Walter Oney Newsgroups: comp.os.ms-windows.programmer.vxd Subject: Re: Changing Oneys IFSMonitor Date: Wednesday, November 26, 1997 6:19 AM Frank wrote: > When "VWIN32_QueueUserApc" is called I'd like to wait for a response > from the ring3 code, so that it results in a synchronous call. Don't do this! It will hang the system. In general, you dare not "call" a Win32 program in ring-3 from a VxD. I.e., don't send it an APC or post it a window message and then wait for it to reply somehow. Deadlocks frequently result, but not always. It works just often enough to encourage developers to go way too far down this blind alley. Many people seem to want to do what you're describing in order to implement a security extension of some kind. You simply have to archictect your application so that your file system hook can handle everything on its own, possibly using data generated and previous supplied by an application. If you need to interact with the user in real time, you have to use a blue screen by calling SHELL_SYSMODAL_Message. If you need to communicate over the network, you have to call TDI (or IPX, or whatever) at the VxD level. ====================================================================== Date: Tue, 25 Nov 1997 06:34:37 -0500 Sender: Windows and Windows NT Device Driver Development From: Walter Oney Organization: Walter Oney Software Subject: Re: 9X: To: DDK-L@PEACH.EASE.LSOFT.COM Ian Ash wrote: > Yip, that is how I did it - I would PostMessage to my app then > then _BlockOnID and _SignalID when the app called my vxd with a > DeviceIOControl. However, it doesn't seem to work perfectly, with > it crashing the system totally in some instances. What appeared > to happen was that the message was never getting through to the > application. As I told the original poster in response to his private e-mail, you're pretty much guaranteed to deadlock if you try to dive back into ring 3 and block while handling a file system request. KERNEL32 owns a Mutex across its call to ring-0 to handle file system requests, and the same Mutex is required in order to process the APC in some cases. It's simply not safe to rely on ring-3 routines to act as a subroutine for a VxD. Microsoft never designed the system to work that way, and it's silly to try. Most of the time I hear this question (and it seems to come up a lot!) is in the context of security add-ons. It seems to me that whatever processing would occur in ring-3 could perfectly well be done in ring-0 using data shared with the controlling application. This would include querying some network server by directly calling MSTCP via TDI. The only exception would be if you need to ask the user permission in real time. You could use SHELL_SYSMODAL_Message for that purpose; the shocking blue screen you'd get would correctly indicate to the user that some alarming event is about to take place for which permission is required right now. The one circumstance where you could call ring-3 would be if you were going to call a 16-bit function that didn't use any of the Windows API. You could use a nested execution block to run the function in ring-3. But, since the function can't interact with the user, why not just put the algorithm in ring-0 and avoid the complication? ====================================================================== From: "Martin Borve" Subject: Re: Can a FSD call a ring3 APP and block until win32 APP does the request ? Newsgroups: comp.os.ms-windows.programmer.vxd References: <01bc2619$7936be80$a969cad0@newmicronpc> Organization: Microsoft Corp. Message-ID: <01bc2848$e8694260$763679a8@superfast200> X-Newsreader: Microsoft Internet News 4.70.1155 FSDs should never call back into Win32 to complete an I/O request. Win32 will sometimes take ownership of an internal mutex (not the Win16mutex) before making I/O requests, and not release the mutex until after the I/O operation completes. One effect of holding this mutex is that it prevents any thread switches, which means you will deadlock when you try to call back into Win32. FSDs should only complete an I/O request in ring 0, or in V86 mode (such as the real-mode mapper). FSDs should never rely on Win32 code. -Martin ====================================================================== Path: mindspring!newsfeed.internetmci.com!news.maxwell.syr.edu!news.alt.net!newspost1.alt.net!usenet From: raymondc@microsoft.com.--- (Raymond Chen) Newsgroups: comp.os.ms-windows.programmer.vxd Subject: Re: Calling Ring 3 from IFS Hook causes Ring 3 to hang Date: Sat, 31 May 1997 16:25:19 GMT Organization: Microsoft Corporation Lines: 30 Message-ID: <3396502a.59725036@157.55.96.156> References: <01bc6c59$38a81540$3800a8c0@test1> <33906849.44458554@157.55.96.156> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Newsreader: Forte Agent 1.01/32.397 On Fri, 30 May 1997 09:49:22 -0400, tyetiser@prolog.net.com (Tarkan Yetiser) wrote: >How do you block ring3? You're blocking maybe a thread in ring3. Remember that large portions of ring 3 are cooperatively multi-tasking. (For example, all 16-bit applications.) So if you prevent a single ring 3 thread from running, and that thread happens to be in cooperative multi-tasking mode, no other threads will run because they are waiting for the thread you blocked. Note also that ring 3 applications can explicitly disable multi-tasking; for example, taking a DirectDraw video surface lock will disable multi-tasking until the surface is subsequently unlocked. >Can't you block the requesting thread, do stuff in Ring0, and then >wake up the thread? If you handle the request entirely at ring 0 then you're okay. But if you rely on ring 3 to complete the request, you end up in a deadlock. >How are the FSDs handling requests from multiple threads? At ring 0. ====================================================================== Path: mindspring!cpk-news-hub1.bbnplanet.com!news.bbnplanet.com!howland.erols.net!ix.netcom.com!zdc-e!super.zippo.com!szdc!zippo!drn From: Somnath Kundu Newsgroups: comp.os.ms-windows.programmer.vxd Subject: Re: Calling Ring 3 from IFS Hook causes Ring 3 to hang Date: 29 May 1997 22:59:01 -0700 Organization: None Lines: 56 Message-ID: <5mlqb5$dfj@drn.zippo.com> References: <01bc6c59$38a81540$3800a8c0@test1> Hello, I think your scheme should work fine as far as all the file I/O request are coming from Win32 applications. Though 32-bit threads are preemptively multitask in Win95, but Win16 subsystem still runs as a cooperative multitasking system. To smoothly run older 16-bit applications in Win95, there is mutual exclusion scheme in Win95 named Win16Mutex. Any thread which owns Win16Mutex (a semaphore) is not scheduled preemptively. A 16-bit thread owns the Win16Mutex through out its entire life and 32-bit threads also grab Win16Mutex whenever they thunk down to 16-bit code. If any file I/O request from 16-bit code or 32-bit thread which owns Win16Mutex is blocked system will be in a dead lock situation. In essence you scheme will not work if file I/O request comes from a 16-bit application or a 32-bit application (thread) which owns Win16Mutex. Regards, Somnath Kundu. In article <01bc6c59$38a81540$3800a8c0@test1>, "Todd says... > >I have an IFS hook VxD that monitors all I/O calls destined for a certain >subdirectory. When an I/O call comes in for that subdirectory, I send >information about that I/O request up to a ring 3 app. The VxD then blocks >and waits for the ring 3 app to do some processing on the I/O call and >return some data back to the VxD. The whole purpose of this is to redirect >the I/O calls for the given subdirectory to another location. > >The VxD and ring 3 app use shared memory buffers to actually transfer the >data, and I've tried using both APC's and events to notify ring 3 that it >has some data to process. In the case of APC's, I queue the APC and then >block using IFSMgr_Block. Ring 3 uses DeviceIoControl to notify the VxD >that the results are ready, which does the IFSMgr_Wakeup. > >Everything works fine for a while, but sometimes the APC doesn't get >called. When that happens, the VxD blocks with the IFSMgr_Block and all of >the ring 3 applications appear to hang. Since the APC isn't executed, the >system is effectively deadlocked, although I can still break into SoftIce. > >One thing that I've noticed to be consistent is that every call into the >IFS hook seems to be inside the global critical section. Since I don't >want to be in the critical section while I'm blocking, I exit the critical >section right before I block, and reenter it right after the IFSMgr_Wakeup. > >Does anyone see anything wrong with this approach or have a better way to >do it? My main problem is that the system deadlocks intermittently, and I >don't know why. At this point I'm open to any suggestions on how to >address this, and any help would be greatly appreciated. > >Thanks in advance. > >Todd T. Snoddy > ====================================================================== Path: mindspring!cpk-news-hub1.bbnplanet.com!cam-news-hub1.bbnplanet.com!news.bbnplanet.com!news.mathworks.com!news.pbi.net!news.PBI.net!nitrog From: "John Glavin" Newsgroups: comp.os.ms-windows.programmer.vxd Subject: Can a FSD call a ring3 APP and block until win32 APP does the request ? Date: 1 Mar 97 07:12:23 GMT Organization: Pacific Bell Internet Services Lines: 24 Message-ID: <01bc2619$7936be80$a969cad0@newmicronpc> NNTP-Posting-Host: nitrogen-c.themall.net X-Newsreader: Microsoft Internet News 4.70.1155 I am trying to use a ring 3 WIN32 app to perform requests for a FSD (network redirector). When IFS call's my VXD to open a file, or read from a file, I would call Create_Semaphore and then call VWIN32_QueueUserAPC to queue up a callback to my WIN32 APP. Then in the VXD I would wait on the semaphore. The WIN32 APP APC would occur and perform the task, then call back into the VXD to release the semaphore allowing the original IFS request that is waiting on Wait_Semaphore to continue. This seems to work much of the time but sometimes it hangs my system when the VXD calls Wait_Semaphore. When this happens the WIN32 APC is never called. So my question is what I'm attempting to do possible in a FSD ? Some documentation I have seen says never to block a VXD during a callback, and that you can't call VWIN32_QueueUserAPC unless you are running under the system VM. Any info would be appreciated, please respond by post and e-mail ====================================================================== Sender: CPB@ATIS4 Newsgroups: comp.os.ms-windows.programmer.vxd Subject: Re: Can a FSD call a ring3 APP and block until win32 APP does the request ? References: <01bc2619$7936be80$a969cad0@newmicronpc> From: c.paul.bond@cpmx.saic.com (C. Paul Bond) Date: 03 Mar 1997 12:09:48 -0500 Message-ID: Lines: 35 X-Newsreader: Gnus v5.3/Emacs 19.33 Path: mindspring!cpk-news-hub1.bbnplanet.com!cam-news-hub1.bbnplanet.com!news.bbnplanet.com!news.mathworks.com!mvb.saic.com!news.saic.com!atis4 Nntp-Posting-Host: News.Saic.Com "John Glavin" writes: > I am trying to use a ring 3 WIN32 app to perform requests for a FSD > ... My guess is that you have run into the Win16Mutex. Win16Mutex is a global semaphore that is used to protect the 16-bit Windows 95 components from being reentered by preventing Win32 threads from thunking to 16-bit components while other 16-bit code is running. When a 16-bit application is running Windows 95 behaves just like Windows 3.1, that is *non-preemptive*. If your VXD is servicing a request from a 16-bit application then no other application will be run until the request form the 16-bit application is completed. I think that the only what to get this to work is to call a 16-bit DLL to do the work using Simulate_Far_Call or do all the work in the VxD. C. Paul Bond, Senior Software Engineer, SAIC, C.Paul.Bond@cpmx.saic.com ====================================================================== X-Mailer: Mozilla 3.0Gold (WinNT; U) Date: Sat, 5 Jul 1997 19:39:24 +0100 Reply-To: Windows and Windows NT Device Driver Development Sender: Windows and Windows NT Device Driver Development From: Joe Cossette Subject: Re: fsd, 9x:DDK-L@PEACH.EASE.LSOFT.COM To: DDK-L@PEACH.EASE.LSOFT.COM Walter Oney wrote: > > Sashi wrote: > > I am making Windows 95 network redirector(VxD) ... > > All the communication module are Win32 .DLL. > > There's simply no way to make this work. The deadlock you notice with > CreateFile will crop up all over the place whenever you dive back into > ring-3 to handle FSD requests. You will have to do all of your network > communications entirely in ring-0. If you can use TCP/IP, you'll be able > to use VTDI (which is at > ftp://ftp.microsoft.com/developr/drg/WinSock/MS-Extensions/vxdtdi.zip). Walt is right... I addressed some of these issues in a few posts some time back...We tried doing the same thing for an IP Tunneling driver we were writing... we thought we might be able to intercept all packets at ring0 and pass them up to a ring3 app for further processing (encryption/authentication, etc.,...). But MS's higher level net software (redirector/server) expects all packets arriving at ring0 and just sat spinning waiting for a packet to arrive... which resulted in the ring3 app thread never getting scheduled... so effectively it was a deadlocked (actually, the net code would eventually time out after some long timeout periods, during which just about the whole system hung except for interrupt routines...;)... Hope this helps. -- Joe Cossette Syzygy International Corp. ======================================================================