Microsoft has published information about the implementation of VFS in the Linux subsystem on Windows 10
In previous posts we covered some elements of the Linux subsystem implementation in Windows 10 (WSL). In this case, it was about the implementation mechanisms of Linux system services based on Windows 10 system modules. We indicated that drivers such as LXss.sys and LXCore.sys are responsible for implementing the semantics of Linux system calls using the Windows kernel. If the semantics of the Linux and Windows system service coincide, the aforementioned drivers simply redirect the Linux system call to the corresponding equivalent of Windows.
This post will discuss the implementation of a virtual file system VFS in WSL, which is used as a level of abstraction in Linux when accessing both disk files and other OS objects, including devices, ports, processes, microprocessor, etc. Since The Windows 10 kernel has a subsystem structure and is originally designed to implement various types of environments, including POSIX, the VX semantics responsible for the LXCore.sys driver refers to these kernel subsystems, implementing the corresponding semantics and directories like / dev, / proc, / sys.
')
Fig. General scheme of VFS implementation in WSL. At the top level are Linux applications that call the OS API, the kernel-mode driver LXCore.sys is responsible for their implementation. To implement VFS semantics, the driver accesses various Windows kernel subsystems, including Object Manager (ObMgr) for working with the Windows name system and Object Manager's namespace, Input / Output Manager (IoMgr) for implementing the / dev directory, and the file system driver NTFS for working with disk files.
WSL provides Linux applications with the necessary VFS semantics, while maintaining the permissions of files and directories, symbolic links, special files such as FIFOs, as well as the aforementioned directories / dev, / proc, / sys, etc. When an application calls one of the functions such as open , read , chmod , stat , the corresponding system call is taken for its processing and transfers control to the VFS implementation layer (LXCore.sys). Further, when processing file paths (for example, when executing the open and stat functions), VFS converts it to an internal format using a special cache (directory entry cache). In the absence of the required path element in the cache, one or several special plug-ins (see below) are called to create a known inode structure for this element. This structure will represent the application-opened file in the WSL.
Windows does not have an inode structure to represent an open file descriptor; instead, it uses a well-known structure called file object that stores some information about the file (size, attributes, access mask, etc.). LXCore.sys relies on it internally when implementing inode. However, both Linux and Windows use file descriptors to represent the open file, the details of which are hidden by LXCore.sys. It defines the levels of so-called plug-ins called VolFs and DrvFs, which are responsible for working with disk files, TmpFs for working with in-memory file system data, as well as pseudo-FS ProcFs, SysFs, and CgroupFs.
VolFs
The VolFs plugin is used by VFS to work with a disk file system, it is used to store Linux system files, as well as the contents of the / home directory. VolFs supports working with Linux file permissions, symbolic links, sockets, device files, and FIFO. The / root and / home directories are mounted in the% LocalAppData% \ lxss \ root and% LocalAppData% \ lxss \ home directories. When the WSL subsystem is deleted, the files stored in these directories are not deleted. As can be seen from the path, the directory mounting directories for Linux depend on a specific user, that is, each Windows user has its own WSL directory. Therefore, installing Linux applications in WSL by one user will not affect others.
WSL provides applications with two Linux file system features that are not directly supported in Windows. The first such feature is the sensitivity of the file system to the register of file names, in which case VolFs simply refers to the object manager, specifying a specific flag for the operation. Since NTFS internally distinguishes the case of file name characters, the implementation of this feature is quite a simple task.
The second feature is the support of almost all possible characters as applicable to file names. Windows has more stringent restrictions on file names, some characters in file names are invalid, and others may have a special meaning, such as the colon character ":", indicating an alternate data stream in the file. When implementing this feature, VolFS avoids the use of invalid characters in the titles.
Linux inodes have a number of attributes that are missing in Windows, including owner and group information, as well as mode. These attributes are stored in the NTFS Ea extended attribute structure that is associated with the files on the disk. This attribute of the NTFS Ea file stores the following information:
DrvFs
To facilitate interaction with Windows, WLS uses the DrvFs plugin. WSL automatically mounts all disk devices with supported file systems into the / mnt directory, for example, / mnt / c, / mnt / d. Currently supported volumes with NTFS and ReFS file systems. DrvFs work in the same way as VolFs. When a thread opens a file descriptor, file object and inode structures are created. However, unlike VolFs, DrvFs adheres to the Windows rules when working with the file system. It uses permissions for files from Windows, only legal NTFS file names, while special files such as FIFO and sockets are not allowed.
Linux is known to use a fairly simple permissions model when a file owner, group, or anyone else is allowed to execute, read, or write data. Windows uses a more complex model based on Access Control Lists (ACL), which define complex access rules for each individual file or directory (Linux also has the ability to support ACL, but this function is not currently supported by WSL).
When a file is opened via the DrvFs plugin, it uses the Windows permissions mechanism based on the access token of the user in whose context the bash.exe command interpreter process was started. Thus, to access files in the C: \ Windows system directory, it is not enough just to use the sudo command , which can grant root privileges in the WSL. The latter does not change the access token of the process, so to perform this operation, you must run the bash application with elevated privileges in Windows.
WSL can give the user a hint about the permissions he has when accessing files, while DrvFs checks the user's current permissions and converts them into the read / write / execute bits that can be seen when executing the “ls -l” command. However, it is not always possible to directly transform; for example, Windows has separate permissions for the ability to create files or subdirectories in a directory. If the user has such permissions, DrvFs will indicate the presence of write access to the directory, while some operations with it may not be available to him.
Since the specified WLS access to the file may vary depending on what rights the bash.exe process runs in Windows, the specified permissions to access the files will change when switching between copies of bash.exe with different rights (one started from a simple user, and the second from the administrator). When calculating file access permissions, DrvFs takes the read-only attribute into account. A file with a read-only attribute will be displayed in WSL as not having write permission. The chmod command can be used to set the read-only attribute (by removing all write permissions, i.e. chmod aw some_file ) or removing it (by setting any write permission, i.e. chmod u + w some_file ). This WSL behavior is similar to the CIFS file system on Linux, which is used when accessing Windows SMB shares.
Unlike VolFs, DrvFs do not store any additional information about files. Instead, all inode attributes are generated based on information that is used in Windows by querying valid file attributes, effective permissions, and other information. DrvFs also prohibits the use of a special directory cache (directory entry cache). This is done to keep it constantly up to date, even when one of the other Windows processes modifies the contents of a directory. Thus, there are no restrictions on what Windows processes can do with files, as long as DrvFs also have access to them. DrvFs also use the Windows semantics when deleting files, so that the file cannot be unlinked if there are any open handles to it.
ProcFs and SysFs
In the case of Linux, these types of special directories do not work with disk files, instead providing information that the OS kernel has about running processes, streams, devices used. These directories are dynamically generated when the client attempts to read them. In some cases, information for these directories is stored entirely in LXCore.sys memory. In other cases, for example, using a microprocessor by any of the processes, the WSL requests this information from the Windows kernel. However, in both cases, the plug-ins do not interact with Windows disk file systems.
This post will discuss the implementation of a virtual file system VFS in WSL, which is used as a level of abstraction in Linux when accessing both disk files and other OS objects, including devices, ports, processes, microprocessor, etc. Since The Windows 10 kernel has a subsystem structure and is originally designed to implement various types of environments, including POSIX, the VX semantics responsible for the LXCore.sys driver refers to these kernel subsystems, implementing the corresponding semantics and directories like / dev, / proc, / sys.
')
Fig. General scheme of VFS implementation in WSL. At the top level are Linux applications that call the OS API, the kernel-mode driver LXCore.sys is responsible for their implementation. To implement VFS semantics, the driver accesses various Windows kernel subsystems, including Object Manager (ObMgr) for working with the Windows name system and Object Manager's namespace, Input / Output Manager (IoMgr) for implementing the / dev directory, and the file system driver NTFS for working with disk files.
WSL provides Linux applications with the necessary VFS semantics, while maintaining the permissions of files and directories, symbolic links, special files such as FIFOs, as well as the aforementioned directories / dev, / proc, / sys, etc. When an application calls one of the functions such as open , read , chmod , stat , the corresponding system call is taken for its processing and transfers control to the VFS implementation layer (LXCore.sys). Further, when processing file paths (for example, when executing the open and stat functions), VFS converts it to an internal format using a special cache (directory entry cache). In the absence of the required path element in the cache, one or several special plug-ins (see below) are called to create a known inode structure for this element. This structure will represent the application-opened file in the WSL.
Windows does not have an inode structure to represent an open file descriptor; instead, it uses a well-known structure called file object that stores some information about the file (size, attributes, access mask, etc.). LXCore.sys relies on it internally when implementing inode. However, both Linux and Windows use file descriptors to represent the open file, the details of which are hidden by LXCore.sys. It defines the levels of so-called plug-ins called VolFs and DrvFs, which are responsible for working with disk files, TmpFs for working with in-memory file system data, as well as pseudo-FS ProcFs, SysFs, and CgroupFs.
VolFs
The VolFs plugin is used by VFS to work with a disk file system, it is used to store Linux system files, as well as the contents of the / home directory. VolFs supports working with Linux file permissions, symbolic links, sockets, device files, and FIFO. The / root and / home directories are mounted in the% LocalAppData% \ lxss \ root and% LocalAppData% \ lxss \ home directories. When the WSL subsystem is deleted, the files stored in these directories are not deleted. As can be seen from the path, the directory mounting directories for Linux depend on a specific user, that is, each Windows user has its own WSL directory. Therefore, installing Linux applications in WSL by one user will not affect others.
WSL provides applications with two Linux file system features that are not directly supported in Windows. The first such feature is the sensitivity of the file system to the register of file names, in which case VolFs simply refers to the object manager, specifying a specific flag for the operation. Since NTFS internally distinguishes the case of file name characters, the implementation of this feature is quite a simple task.
The second feature is the support of almost all possible characters as applicable to file names. Windows has more stringent restrictions on file names, some characters in file names are invalid, and others may have a special meaning, such as the colon character ":", indicating an alternate data stream in the file. When implementing this feature, VolFS avoids the use of invalid characters in the titles.
Linux inodes have a number of attributes that are missing in Windows, including owner and group information, as well as mode. These attributes are stored in the NTFS Ea extended attribute structure that is associated with the files on the disk. This attribute of the NTFS Ea file stores the following information:
- File Mode (mode): includes the file type (normal, symbolic link, FIFO, etc.), as well as the permission bits for the file.
- Owner Information: The group ID and user of the owners of the file.
- Device ID: for files that represent devices, major and minor device numbers. So far, WSL does not allow users to create device files on VolFS.
- File timestamps: the timestamps of the last access to the file and its modification. Linux uses a different timestamp format, so information about them is stored in extended attributes.
DrvFs
To facilitate interaction with Windows, WLS uses the DrvFs plugin. WSL automatically mounts all disk devices with supported file systems into the / mnt directory, for example, / mnt / c, / mnt / d. Currently supported volumes with NTFS and ReFS file systems. DrvFs work in the same way as VolFs. When a thread opens a file descriptor, file object and inode structures are created. However, unlike VolFs, DrvFs adheres to the Windows rules when working with the file system. It uses permissions for files from Windows, only legal NTFS file names, while special files such as FIFO and sockets are not allowed.
Linux is known to use a fairly simple permissions model when a file owner, group, or anyone else is allowed to execute, read, or write data. Windows uses a more complex model based on Access Control Lists (ACL), which define complex access rules for each individual file or directory (Linux also has the ability to support ACL, but this function is not currently supported by WSL).
When a file is opened via the DrvFs plugin, it uses the Windows permissions mechanism based on the access token of the user in whose context the bash.exe command interpreter process was started. Thus, to access files in the C: \ Windows system directory, it is not enough just to use the sudo command , which can grant root privileges in the WSL. The latter does not change the access token of the process, so to perform this operation, you must run the bash application with elevated privileges in Windows.
WSL can give the user a hint about the permissions he has when accessing files, while DrvFs checks the user's current permissions and converts them into the read / write / execute bits that can be seen when executing the “ls -l” command. However, it is not always possible to directly transform; for example, Windows has separate permissions for the ability to create files or subdirectories in a directory. If the user has such permissions, DrvFs will indicate the presence of write access to the directory, while some operations with it may not be available to him.
Since the specified WLS access to the file may vary depending on what rights the bash.exe process runs in Windows, the specified permissions to access the files will change when switching between copies of bash.exe with different rights (one started from a simple user, and the second from the administrator). When calculating file access permissions, DrvFs takes the read-only attribute into account. A file with a read-only attribute will be displayed in WSL as not having write permission. The chmod command can be used to set the read-only attribute (by removing all write permissions, i.e. chmod aw some_file ) or removing it (by setting any write permission, i.e. chmod u + w some_file ). This WSL behavior is similar to the CIFS file system on Linux, which is used when accessing Windows SMB shares.
Unlike VolFs, DrvFs do not store any additional information about files. Instead, all inode attributes are generated based on information that is used in Windows by querying valid file attributes, effective permissions, and other information. DrvFs also prohibits the use of a special directory cache (directory entry cache). This is done to keep it constantly up to date, even when one of the other Windows processes modifies the contents of a directory. Thus, there are no restrictions on what Windows processes can do with files, as long as DrvFs also have access to them. DrvFs also use the Windows semantics when deleting files, so that the file cannot be unlinked if there are any open handles to it.
ProcFs and SysFs
In the case of Linux, these types of special directories do not work with disk files, instead providing information that the OS kernel has about running processes, streams, devices used. These directories are dynamically generated when the client attempts to read them. In some cases, information for these directories is stored entirely in LXCore.sys memory. In other cases, for example, using a microprocessor by any of the processes, the WSL requests this information from the Windows kernel. However, in both cases, the plug-ins do not interact with Windows disk file systems.
Source: https://habr.com/ru/post/303438/
All Articles