Microsoft revealed the technical aspects of the implementation of the Linux subsystem in Windows 10
In our previous posts, we talked about Microsoft’s intention to include the Ubuntu Linux subsystem in Windows 10. The executable files of the subsystem appeared in the OS starting with Windows 10 Insider Preview Build 14251, for use it became available in Insider Preview Build 14316, and for all Windows 10 users it will be available with Microsoft promised a great June update, i.e. this month. To use the subsystem, it will need to be enabled by a special setting, since it is turned off by default. The process of inclusion, we described in this post.
Microsoft calls the Linux subsystem for Windows as Windows Subsystem for Linux (WSL). Today the company has published new technical details of the implementation of WSL. We have previously written about the model of subsystems in Windows 10 (NT) and how WSL is implemented at the Windows kernel level due to the drivers LXss.sys and LXCore.sys. Since the original Windows kernel model allows the top level of components (for example, ntdll.dll - Win32) to use its semantics of system calls due to the extended kernel interface, WSL has no problems with its implementation in the Windows environment.
')
Fig. An example of the implementation of the service to get a list of files in a directory. The kernel mode driver LXss.sys implements the semantics of the ls command by using the ntoskrnl! NtQueryDirectoryFile kernel interface, which allows it to do so. The same operation for the Windows subsystem is performed by the ntdll.dll component, referring to ntoskrnl! NtQueryDirectoryFile directly (on the right).
An interesting feature is the implementation of Linux system calls in the new subsystem, since this function is the most important operation when running Linux programs. A system service is a call to a kernel function to perform a basic action in the OS, passing arguments to it. Such actions include operations with files, processes, network, etc. To call the service, a microprocessor instruction called syscall is used , which transfers control to the kernel mode and calls the service control manager.
Microsoft refers to the rules for invoking a system service as the Application Binary Interface (ABI). The ABI feature for WSL is that it does not completely match the one used in Windows. Below are the differences in passing arguments to the system service in the case of identical operations — the getdents64 service on Linux and NtQueryDirectoryFile on Windows. A description of the Linux service arguments is here .
Fig. Differences in ABI between Linux and Windows.
The difference lies in both the Windows and Linux registers used, and in the number of system services that must be transferred in the rax register. The above table shows this difference, with the other ABI steps being identical, the arguments of both services are placed in the registers and the syscall call is made . Another difference lies in the statuses returned by the Linux and Windows services. While Windows uses special NTSTATUS negative constants, Linux uses a different numbering system for the status of operations performed. After calling the WLS system service, control is transferred to the Windows system services manager, which, in unchanged form, sends a LXss.sys request that implements the corresponding semantics.
The LXss.sys driver can simply invoke the Windows system service without providing additional semantics for it. This applies to those services whose implementation semantics are the same for both OSs. For example, the Linux sched_yield function corresponds to a Windows service called ZwYieldExecution , which has the same semantics. This function instructs the kernel to transfer the microprocessor to another thread. WLS will not take any additional action, but will simply call ZwYieldExecution . In other cases, for example, when implementing pipe work functions and fork fork processes, LXss.sys implements the corresponding semantics based on the basic functions and synchronization primitives of the Windows kernel.
Microsoft calls the Linux subsystem for Windows as Windows Subsystem for Linux (WSL). Today the company has published new technical details of the implementation of WSL. We have previously written about the model of subsystems in Windows 10 (NT) and how WSL is implemented at the Windows kernel level due to the drivers LXss.sys and LXCore.sys. Since the original Windows kernel model allows the top level of components (for example, ntdll.dll - Win32) to use its semantics of system calls due to the extended kernel interface, WSL has no problems with its implementation in the Windows environment.
')
Fig. An example of the implementation of the service to get a list of files in a directory. The kernel mode driver LXss.sys implements the semantics of the ls command by using the ntoskrnl! NtQueryDirectoryFile kernel interface, which allows it to do so. The same operation for the Windows subsystem is performed by the ntdll.dll component, referring to ntoskrnl! NtQueryDirectoryFile directly (on the right).
An interesting feature is the implementation of Linux system calls in the new subsystem, since this function is the most important operation when running Linux programs. A system service is a call to a kernel function to perform a basic action in the OS, passing arguments to it. Such actions include operations with files, processes, network, etc. To call the service, a microprocessor instruction called syscall is used , which transfers control to the kernel mode and calls the service control manager.
Microsoft refers to the rules for invoking a system service as the Application Binary Interface (ABI). The ABI feature for WSL is that it does not completely match the one used in Windows. Below are the differences in passing arguments to the system service in the case of identical operations — the getdents64 service on Linux and NtQueryDirectoryFile on Windows. A description of the Linux service arguments is here .
Fig. Differences in ABI between Linux and Windows.
The difference lies in both the Windows and Linux registers used, and in the number of system services that must be transferred in the rax register. The above table shows this difference, with the other ABI steps being identical, the arguments of both services are placed in the registers and the syscall call is made . Another difference lies in the statuses returned by the Linux and Windows services. While Windows uses special NTSTATUS negative constants, Linux uses a different numbering system for the status of operations performed. After calling the WLS system service, control is transferred to the Windows system services manager, which, in unchanged form, sends a LXss.sys request that implements the corresponding semantics.
The LXss.sys driver can simply invoke the Windows system service without providing additional semantics for it. This applies to those services whose implementation semantics are the same for both OSs. For example, the Linux sched_yield function corresponds to a Windows service called ZwYieldExecution , which has the same semantics. This function instructs the kernel to transfer the microprocessor to another thread. WLS will not take any additional action, but will simply call ZwYieldExecution . In other cases, for example, when implementing pipe work functions and fork fork processes, LXss.sys implements the corresponding semantics based on the basic functions and synchronization primitives of the Windows kernel.
Source: https://habr.com/ru/post/302976/
All Articles