What are the rules for making a R0 read/write call from an IOS port driver?

What are the rules for making a R0 read/write call from an IOS port driver?

Conventional IFSMGR_Ring0_FileIO typically will not work when called from within an IOS port driver if attempting to open and use a file located on a local (FAT) drive. This is because of blocking that can occur in VFAT. VFAT uses IFSMGR_Block to serialize use of FAT data structures (and prevent VFAT data structure corruption due to re-entrance). Also there is a flag in VFAT called FullHold, which keeps track of the count of threads in VFAT and establishes a "full critical section" that is VFAT-global (not specific to a single drive letter). Attempts to perform IFSMGR_Ring0_FileIO fail (block) when called from a port driver, since the original port request went through VFAT; the subsequent Ring0 file call gets blocked by FullHold. However, success has been reported by developers outside of Microsoft, if the file is opened as a memory mapped file, under Windows 95 through Windows 98. With memory mapped files, IFS Manager performs fewer tests for sharing violations. Therefore you should set up a private memory-mapped file so it is not opened by any program other than yours. Also, all your I/O requests should be page (4K) aligned.

mov al,byte ptr [function] ; (al) = read (3f) or write(40)

sub al,3fh ; (al) = read (0) or write (1)

xor ecx,ecx

mov edx,[fileloc] ; (edx) = seek position

mov ecx,[cbLen] ; (ecx) = number of bytes in i/o

mov esi,[memloc] ; (esi) = transfer address

VxDCall IFSMgr_Ring0_FileIO ; do the i/o

Trace_OutC "ReadWritePage: error #EAX from file i/o"
Note that the R0_MM_READ_WRITE flag must be set for every I/O operation, not just at file open time.
As long as we are discussing Ring0_FileIo, here is how PAGEFILE VXD opens the swap file (after it has been determined that the swap file can be safely accessed by 32-bit protected mode drivers):
; Open or Create the file
mov eax,R0_OPENCREATFILE ; (eax) = open function code

mov bx,0110000010010010b ; (bx) = flags: r/w, deny all,

; no inherit, no int 24,

; no caching

xor ecx,ecx ; (ecx) = attributes (nothing)

mov dl,00010001b ; (dl) = open mode, open or create

mov dh,((R0_SWAPPER_CALL or R0_NO_CACHE or OPEN_FLAGS_NO_COMPRESS) SHR 8)

; (dh) = special flags

mov esi, offset32 PF_Our_File_Name ; (esi) = file name

VxDCall IFSMgr_Ring0_FileIO ; do the open (eax) = handle

jc osf110 ; jump if error
mov [PF_File_Handle],eax ; save file handle
The original Windows 95 DDK did not mention that the flag bits need to be shifted right 8 positions as shown above. Read/write of the swap file are performed using normal R0_READFILE and R0_WRITEFILE functions, with no special flags set.
Here is a reportedly successful implementation of an IOS port driver that uses the above R0_MM_READ_WRITE Ring0_FileIo to access a local FAT file:

1. 
   Open the file with the following flags: R0_OpenFile(R0_NO_CACHE | R0_MM_READ_WRITE)
   
2. 
   CreateSemaphore()
   
3. 
   VWIN32_CreateRing0Thread()
   
4. 
   Set_Thread_Win32_Pri(16) - other values may work
   
5. 
   Set a worker thread running:
   Thread()
   while not stop
   Wait_Semaphore(BLOCK_THREAD_IDLE)
   Dequeue IOP
   Do R0 file I/O
   Do CallBack
   endwhile
   
6. 
   The IOP Handler:
   IOHandler(IOP)
   if read or write
   Enqueue IOP
   Signal_Semaphore()
   return
   endif
   

Also, the developer reported the need to do periodic forced volume flushes to the memory mapped file (virtual drive) when a long file is being copied to it. This is done using IFSMGR_InstallFileSystemApiHook. Upon write operations to the virtual volume a data byte counter is incremented, and direct calls to volume's flush function through its function table occur, if the counter = 1Mb. Without this, the reading of the file from system volume slows down and would ultimately result in being locked up in Ring0_FileIo.

How does Windows 95 itself use IFSMGR_Ring0_FileIo?

The following is an abbreviated analysis of how Windows 98’s DriveSpace (DRVSPACX) accesses its host Compressed Volume Files (CVF’s) located on the physical host volume.

1. 
   DRVSPACX only uses the IFSMGR_Ring0_FileIo call when it is handling the AEP_MOUNT_NOTIFY event, in order to find and read the beginning part of all the CVF's (Compressed Volume Files) on a CVF host drive. This event is generated by IOS when IRS_MOUNT_NOTIFY is called. When performing these actions, there doesn't appear to be any special blocking / serialization going on.
   

2. 
   Whenever DRVSPACX does use IFSMGR_Ring0_FileIO to read a CVF (see above), it uses the R0_READFILE_IN_CONTEXT flag.
   

3. 
   For normal compressed volume file I/O, DRVSPACX sets up an IOP and performs direct sector I/O. DRVSPACX apparently automatically accounts for any fragmentation that the file may have on the disk, and knows the starting sector for each CVF file.
   

A global search for IFSMGR_Ring0_FileIO across the Windows 98 source tree reveals the following:

1. 
   DYNAPAGE.VXD still uses it. It appears to be used when creating, auditing or resizing the swap file.
   

2. 
   IOS uses IFSMGR_Ring0_FileIO during initialization when loading VxDs from the %windir%\system\iosubsys directory.
   

Q183173 BUG: IFSMGR_Ring0FileIO / Level 3 Volume Lock Conflict

There is a bug in IFS that affects VxDs that use IFSMGR_Ring0_FileIo. The corresponding Knowledge Base article (Q183173) is reproduced below. Use the on-line Knowledge Base to check for later potential updates to this article.

The article :BUG: IFSMGR_Ring0FileIO / Level 3 Volume Lock Conflict [win95ddk]

can be accessed at this location:

HTTP://SUPPORT.MICROSOFT.COM/SUPPORT/KB/ARTICLES/Q183/1/73.asp

[Q183173] BUG: IFSMGR_Ring0FileIO / Level 3 Volume Lock Conflict

---------------------------------------------------------------------

The information in this article applies to:

- Windows 95 Device Driver Kit (DDK), version 4.0
SYMPTOMS
If you are using IFSMGR_Ring0FileIO services, you might encounter file access problems when you run utility programs, such as DEFRAG, while IFSMGR_Ring0FileIO files are open.
For example, a file opened as ACCESS_READ_WRITE works fine, until you run DEFRAG. After you run DEFRAG, the file attributes erroneously change to ACCESS_WRITEONLY.
CAUSE
There is a bug in IFSMGR_Ring0FileIO that becomes apparent only when a level three volume lock is released and, as a result, the volume release automatically causes the ring 0 file to be re-opened. When the file is re-opened, the file access mode is erroneously set up with the contents of the file action type. For example, a file opened as follows:
mov esi, OFFSET32 R0_szFileName

mov ebx, ACCESS_READWRITE ; 0x0002

xor ecx, ecx

mov edx, ACTION_OPENEXISTING ; 0x0001

mov eax, R0_OPENCREATFILE

VxDCall IFSMgr_Ring0_FileIO

is re-opened with the contents of EDX appearing in EBX. When appearing in EBX, the value ACTION_OPENEXISTING (0x0001) corresponds to ACCESS_WRITEONLY (0x0001).
RESOLUTION
When the level 3 volume lock is released, it re-opens the temporarily-closed files using FS_OPEN calls down to the target FSD (typically VFAT). You can hook IFS using IFSMgr_InstallFileSystemApiHook to correct "reopen" FS_OPENs on the fly before the FSD sees it. To see if a given FS_OPEN is actually a reopen due to a level 3 volume lock release, check for (ir_options & OPEN_FLAGS_REOPEN). In the Windows 95 Device Driver Kit, see header file IFS.h for flag details. When you find one of these, you can further test for ir_pid = -1, which corresponds to a file opened using the ring 0 functions. Change ir_flags to the correct file access method. For example, if ir_flags erroneously contains ACCESS_WRITEONLY, change it to ACCESS_READWRITE. Then let the file-system I/O proceed normally to complete the (corrected) file open.
STATUS
Microsoft has confirmed this to be a bug in the Microsoft products listed at the beginning of this article. We are researching this bug and will post new information here in the Microsoft Knowledge Base as it becomes available.
REFERENCES
Windows 95 Device Driver Kit

Download 0.64 Mb.

Share with your friends: