Restricted Direct Disk Access and Volume Access in Windows

  • Article

Restrictions are in place in the file system and storage stack in Windows to limit direct access to volumes and disk data locations. This article discusses the conditions requiring restricted access and which I/O control requests are affected by these restrictions. Application developers should be aware of these restrictions and how they impact the use of direct disk and direct volume access.

Background

Typically, if a process obtains an exclusive handle on an opened file, it is assumed that the contents of the file are protected from modification by another process. However, certain conditions could allow a process to make modifications to a file opened exclusively by a different process. These conditions are the following:

  • Another process opens the file handle to the underlying volume or to the underlying disk.
  • A process makes changes directly to the disk locations where the file resides.

Corruption or system instability can occur if a program performs a direct write to a volume that is mounted by a file system without first obtaining exclusive access to the volume. This is because the write to the volume may collide with the file system writes. When such a collision occurs, the contents of the volume may be left in an inconsistent state.

To reduce the possibility and effect of these conditions, restrictions are in place in the file system and storage stack to limit direct access to a disk or a volume.

Details of write restrictions to the file system and to the storage stack

  • A file system can write to a volume handle if one or more of the following conditions are true:

    • Condition 1: The sectors that are being written to are boot sectors.

      Note: This condition exists to support programs such as antivirus programs, Setup programs, and other programs that have to update the startup code of the system volume. The system volume cannot be locked.

    • Condition 2: The sectors that are being written to reside outside the file system space.

      Note: The region between the end of the file system space and the end of the volume space is not under the control of the file system. Therefore, there is no reason to require the volume to be locked to write to it.

    • Condition 3: The volume has been locked implicitly by requesting exclusive write access.

    • Condition 4: The volume has been locked explicitly by requesting a lock request or an unmount request.

    • Condition 5: The write request has a SL_FORCE_DIRECT_WRITE flag that indicates that Condition 2 must be bypassed.

      Note: There are file system filters that write to the free space region of a volume without first locking the volume. If required, file system filters can set a flag on the write request that informs the file system to let the write occur. Use of this flag is only available to filters executing in kernel mode.

  • Direct access to a volume or a disk is allowed if the volume is not mounted or if the volume has no file system.
  • The SCSI PASS THROUGH command requesting a SCSI UNMAP/ATA TRIM/WRITE USING TOKEN will also fail when targeting free space outside of a file system IF there is one volume mounted on the disk and it contains a file system.
  • The UDFS file system and the FASTFAT file system limit the changes that are made to the file system and to the storage stack. These changes are limited to the disk type media. Note: Most CD mastering programs write directly to the volume without first locking the volume. Some CD mastering programs will bypass the file system layer. In these cases, such programs write directly to the storage layer. Because the paging file is hosted only on a disk drive, there is no reason to apply the changes that were made to the file system and to the storage stack to optical drives.
  • The storage drivers can write to a disk handle if the following conditions are true:
    • Condition 1: The sectors that are being written to do not fall within a volume. Note: Programs use the sectors that are outside the volumes to store metadata. The partition tables also reside in the sectors that are outside the volumes. Because these sectors are not under the control of any file system, there is no reason to block access to the sectors.
    • Condition 2: The sectors that are being written to fall within a mounted volume that is locked explicitly.
    • Condition 3: The sectors that are being written to fall within a volume that is not mounted or fall within a volume has no file system.
  • The changes to the file system and to the storage stack will also apply to the parity blocks of a volume.
  • The changes to the file system and to the storage stack will apply to 32-bit systems and to 64-bit systems.

Affected I/O control codes and associated commands

In addition to the various WriteFile APIs, there are device I/O control requests that may be used to issue writes to a volume or to a disk. The restrictions set in the file system and in the storage stack will also affect some device I/O control requests. The device I/O control requests include the following commands:

  • IOCTL_STORAGE_MANAGE_DATA_SET_ATTRIBUTES
    • DeviceDsmAction_Trim
    • DeviceDsmAction_OffloadWrite
  • IOCTL_SCSI_PASS_THROUGH
  • IOCTL_SCSI_PASS_THROUGH_DIRECT
    • SCSIOP_WRITE6
    • SCSIOP_WRITE (WRITE10)
    • SCSIOP_WRITE_VERIFY (WRITE_VERIFY10)
    • SCSIOP_WRITE_SAME (WRITE_SAME10)
    • SCSIOP_WRITE_LONG (WRITE LONG10)
    • SCSIOP_XDWRITE (XDWRITE10)
    • SCSIOP_XPWRITE (XPWRITE10)
    • SCSIOP_XDWRITE_READ (XDWRITEREAD10)
    • SCSIOP_WRITE12
    • SCSIOP_WRITE_VERIFY12
    • SCSIOP_WRITE16
    • SCSIOP_WRITE_VERIFY16
    • SCSIOP_WRITE_SAME16
    • SCSIOP_WRITE_LONG16
    • SCSIOP_WRITE_XDWRITE_EXTENDED16
    • SCSIOP_WRITE_COPY
    • SCSIOP_WRITE_COPY_COMPARE
    • SCSIOP_ORWRITE16
    • SCSIOP_WRITE_USING_TOKEN
    • SCSIOP_UNMAP
    • SCSIOP_XDWRITE32
    • SCSIOP_XPWRITE32
    • SCSIOP_XDWRITEREAD32
    • SCSIOP_WRITE32
    • SCSIOP_WRITE_VERIFY32
    • SCSIOP_WRITE_SAME32
    • SCSIOP_ORWRITE32

Note: Starting with Windows 8 and Windows Server 2012, the, file system and storage stack extended the SCSI command coverage and included UNMAP, WRTIE USING TOKEN and 32 byte destructive WRITE commands.

The following group of commands will fail because they are obsolete:

  • IOCTL_ATA_PASS_THROUGH
  • IOCTL_ATA_PASS_THROUGH_DIRECT
    • IDE_COMMAND_WRITE
    • IDE_COMMAND_WRITE_DMA
    • IDE_COMMAND_WRITE_DMA_QUEUED
    • IDE_COMMAND_WRITE_MULTIPLE
    • IDE_COMMAND_WRITE_EXT
    • IDE_COMMAND_WRITE_DMA_EXT
    • IDE_COMMAND_WRITE_DMA_FUA_EXT
    • IDE_COMMAND_WRITE_DMA_QUEUED_EXT
    • IDE_COMMAND_WRITE_DMA_QUEUED_FUA_EXT
    • IDE_COMMAND_WRITE_MULTIPLE_EXT
    • IDE_COMMAND_WRITE_MULTIPLE_FUA_EXT

For the ATA commands, the LBA bit is queried to determine whether the offset was specified in CHS format or in LBA format. Because the system cannot obtain the real geometry, all requests sent in CHS format will fail. This should not be a problem because all modern disks expect an offset in LBA format.

Program compatibility concerns and mitigations

The changes to the file system and to the storage stack may cause some programs to fail. Such programs fail because they use direct access to the disk or to the volume. Starting with Windows 8, applications should use FSCTL_FILE_LEVEL_TRIM to perform UNMAP/TRIM operations on files of a mounted volume. For free space outside a volume, applications should use the DSM IOCTLs to perform UNMAP/TRIM.

The effect on program compatibility is minimal for the following reasons:

  • Backup programs must unmount the volume before they write to the volume. Otherwise, the program writes will collide with file system writes. Such collisions will result in corruption or in system instability.

  • Partitioning programs target partition tables that reside in sectors that are outside the volume regions. File systems do not control such sectors. Because access to these sectors is enabled, the partitioning programs are not affected.

  • Recovery programs will most likely run on volumes that the file system cannot mount. Because access to RAW volumes is enabled, such recovery programs are not affected.

  • Block level encryption programs usually have a filter driver that resides in the disk stack that is underneath the partition manager driver. The filter driver filters I/O that the partition manager driver issues. Therefore, the changes to the file system and to the storage stack do not affect the block level encryption programs. If the filter driver resides in the volume stack, the filter driver will be underneath the file systems. Therefore, the changes to the file system and to the storage stack do not affect the block level encryption programs.

  • CD mastering programs are not affected because the UDFS file system and the FAT32 file system does not perform checks when the file system is mounted on optical drives. However, CD mastering programs can be affected in the following scenario:

    • A program locks its file.
    • The program queries the extents of the file.
    • The program uses a volume handle to write directly to the extents of the file.

    This scenario is not encouraged, however, since it can cause the file metadata to be out of sync. When file metadata is out of sync, file corruption can occur.

Reference

KB Article 942448 - Changes to the file system and to the storage stack to restrict direct disk access and direct volume access in Windows Vista and in Windows Server 2008 https://support.microsoft.com/kb/942448.

 

 

Send comments about this topic to Microsoft