Microsoft розкрила технічні аспекти реалізації підсистеми Linux Windows 10

В наших попередніх публікаціях ми розповідали про намір Microsoft включити підсистему Ubuntu Linux на Windows 10. Виконувані файли підсистеми з'явилися в ОС починаючи з Windows 10 Insider Preview Build 14251, для використання вона стала доступна в Insider Preview Build 14316, а для всіх користувачів Windows 10 вона стане доступна з обіцяним Microsoft великим червневим оновленням, тобто вже в цьому місяці. Для використання підсистеми, її потрібно буде включити спеціальної налаштуванням, т. к. за замовчуванням вона вимкнена. Процес включення ми описували в це пості.



Microsoft називає підсистему Linux для Windows, Windows Subsystem for Linux (WSL). Сьогодні компанія опублікувала нові технічні деталі реалізації WSL. Раніше ми вже писали про модель підсистем в Windows 10 (NT) і те, як WSL реалізується на рівні ядра Windows за рахунок драйверів LXss.sys і LXCore.sys. Так як оригінальна модель ядра Windows дозволяє верхнього рівня компонентів (напр. ntdll.dll — Win32) використовувати свою семантику системних викликів за рахунок розширеного інтерфейсу ядра, у WSL немає проблем зі своєю реалізацією в оточенні Windows.


Рис. Приклад реалізації сервісу отримання списку файлів у директорії. Драйвер LXss.sys у режимі ядра реалізує семантику команди ls за рахунок використання розширеного інтерфейсу ядра ntoskrnl!NtQueryDirectoryFile, який дозволяє їй це робити. Ту ж операцію для підсистеми Windows виконує компонент ntdll.dll, звертаючись до ntoskrnl!NtQueryDirectoryFile безпосередньо (праворуч).

Цікавою є особливість реалізації системних викликів Linux в новій підсистемі, так як дана функція є найважливішою операцією при роботі програм Linux. Системний сервіс представляє з себе виклик функції ядра для виконання базового дії в ОС з передачею йому аргументів. До таких дій відносяться операції з файлами, процесами, мережею і т. д. Для виклику сервісу використовується інструкція мікропроцесора під назвою syscall, яка передає керування в режим ядра і викличе диспетчер управління сервісами.

Microsoft називає правила виклику системного сервісу як Application Binary Interface (ABI). Особливість ABI для WSL полягає в тому, що він не повністю збігається з тим, який використовується в Windows. Нижче представлені відмінності в передачі аргументів системного сервісу в разі ідентичних операцій — сервісу getdents64 на Linux і NtQueryDirectoryFile в Windows. Опис аргументів сервісу Linux перебуває тут.


Рис. Відмінності в ABI між Linux і Windows.

Відмінність полягає як у використовуваних Windows і Linux регістрах, так і в номерах системних сервісів, які повинні бути передані в регістрі rax. Вище в таблиці вказано ця відмінність, при цьому інші кроки ABI є ідентичними, аргументи обох сервісів розміщуються в регістрах і виконується виклик syscall. Інша відмінність полягає і повертаються сервісами Linux і Windows статусах. У той час як Windows використовує спеціальні від'ємні константи NTSTATUS, Linux використовує іншу систему нумерації статусів виконаних операцій. Після виклику системного сервісу WLS, управління передається диспетчеру системних сервісів Windows, який у незмінному вигляді отправлет запит LXss.sys, що реалізує відповідну семантику.

Драйвер LXss.sys може просто викликати системний сервіс Windows без забезпечення для нього додаткової семантики. Це стосується тих сервісів, семантика реалізації яких однакова для обох ОС. Наприклад, функція Linux sched_yield відповідає сервісу Windows під назвою ZwYieldExecution, який має ту ж семантику. Ця функція інструктує ядро передати мікропроцесор у використання іншому потоку. WLS не буде робити будь-яких додаткових дій, а просто викличе ZwYieldExecution. В інших випадках, наприклад, при реалізації функцій роботи з каналами (pipe) і розгалуженні процесів fork, LXss.sys реалізує відповідну семантику спираючись на основні функції і примітиви синхронізації ядра Windows.
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.