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.
    ESET NOD32
    203,00
    Компания
    Поделиться публикацией

    Комментарии 42

      +1
      Я правильно понял, Linux в Windows интегрирован методом преобразования запросов Linux к запросам Windows?
        +5
        Насколько я знаю, никто не скрывал, что Linux On Windows — это как WINE наоборот :). Что буквально несколько вещей реализованы прямо совсем в ядре, вроде вызова fork(), а остальное просто транслируется в соответствующие вызовы NT API (что бы это не означало).
          +1
          Я более того скажу, в Windows NT от рождения был промежуточный уровень системного API, и над ним было несколько надстроек, в частности WinAPI, OS/2 и тот самый POSIX. Но если не ошибаюсь, к Windows 2000 альтернативные API оттуда убрали.
            0
            Разве? Мне казалось, как минимум, POSIX-слой в том или ином виде был во всех версиях, начиная с NT…
              0
              Правильно кажется. Есть там POSIX (хотя, возможно, и неполный).
              0
              Убрали POSIX только к релизу ХР, но он там изначально был довольно урезанный и ограниченный.
              0

              А что, можно придумать другой вариант?

                0
                Можно. Например поставить ядро BSD и преобразовывать вызовы как Windows, так и Linux к нему :)
                0
                Запросы Windows есть трёх основных видов: NT kernel (ntoskrnl.exe), NT Native API (ntdll.dll) и Windows API (все остальные). Обычно используется только последний, его вызовы преобразуется в вызовы Native API, которые в свою очередь преобразуются в вызовы NT kernel (естественно, не все вызовы вышележащих слоев преобразуются 1:1 — могут вообще не преобразовываться, могут преобразовываться только сигнатуры, могут преобразовываться в несколько вызовов со сложной логикой). Судя по доступной информации WSL реализует преобразование вызовов как минимум Linux Kernel API в вызовы NT kernel и, возможно, в вызовы NT Native API, никак не касаясь подсистемы Windows API, работая параллельно ей.
                +2
                А никто не подскажет:

                — проблемы с курсорными клавишами решили или есть решение? Например в mc навигация
                — для разработки могу ли я создавать/использовать симлинки, права доступа на ФС и т.д. при работе с проектами?
                — каким образом правильно прописать во внешнем софте (например в phpStorm) чтобы он использовал не gitbash а стандартный git?
                  0
                  1. Решили. Работает и в стандартном терминале, и в ConEmu.
                  2. Симлинки и права доступа поддерживаются в файловой системе lxss (которая тоже как бы ntfs, и все это выглядит как магия), в /mnt/c/ не работают.
                  3. Пока никак.
                    0
                    1. Только что попробовал, не работает, что мне нужно сделать не подскажете?
                    2. А как использовать чтоб работало — это какая то надастройка или формат ФС? если форматирование выбираю, то винда не предлагает на выбор такой
                    3. Жаль, без этого толк есть, но не полноценно
                      0
                      По поводу 1 я полагаю надо поставить Fast обновления судя по камменту ниже и развернуть обновление
                        0
                        1. Не знаю, я просто запустил и проверил что работает. Гифка http://i.imgur.com/0qRE3oA.gifv
                        2. Ничего, симлинки, права, регистрозависимость, все это работает «внутри lxss». Т.е. в точке монтирования /. Со стороны Windows эти файлы просто лежат в USER\AppData\Local\Lxss.
                      0
                      Насчет первого вопроса: в последнем билде (14361), который вышел вчера, заработали стрелки в mc и стал запускаться tmux.
                        0
                        Cписок изменений находится здесь https://msdn.microsoft.com/en-us/commandline/wsl/release_notes
                      0
                      А если я захочу, например, открыть специальный сокет в ядре для управления сетевыми интерфейсами по netlink-протоколу? Этот LXss-драйвер так же будет перехватывать мои вызовы для работы с сокетом, транслировать их в WinAPI, а затем подсовывать в мой сокет данные в том же виде, в котором они пришли бы от Linux-ядра? Что-то я в это не верю…
                        0
                        О чем вы говорите, там сейчас даже icmp протокол не поддерживается.
                          0
                          Я сомневаюсь, что LXss будет полностью совместим с ядром Linux. Поэтому никаких AF_NETLINK, AF_BLUETOOH, никаких cgroups и прочих ништяков.
                            0
                            cgroups вполне может и реализуют ради нативного докера с линь контейнерами
                            0
                            LXss не транслирует вызовы в WinAPI, он транслирует их (судя по всему) в вызовы LXCore, которые транслирует их в вызовы ntkernel. Так же как вызовы WinAPI (например вызовы user.dll) транслируются в вызовы ntdll, а затем транслируются в вызовы ntkernel. То есть LXss и WinAPI работают параллельно, возможно даже LXCore и ntdll работают параллельно.
                            –2
                            А вот этот «LINE» (т.е. WINE наоборот) — не будет ли новым глубоким источником дыр в безопасности для ВинОС?
                              0
                              LinE уже был.

                              https://sourceforge.net/projects/line/
                              0
                              Есть уже информация, чем LXss.sys от LXCore.sys отличается?
                                +1
                                Больше интересует, были ли сподвижки в сторону драйверов для «немножко других файловых систем»? будет ли поддержка ext, например?
                                  +1
                                  Вряд ли были, вряд ли будут. Например, есть максимально нативная реализация драйвера btrfs (сырая, но все-таки), и там в readme автор написал, что драйверу приходится «прикидываться» что это NTFS, потому что:
                                  the function MPR!MprGetConnection checks the filesystem type against an internal whitelist, and fails if it's not found, which prevents UAC from working. Thanks Microsoft!

                                  То есть если windows где-то имеет захардкоженные списки «хороших» типов ФС, они явно не рассчитывают на расширяемость, даже сторонними драйверами.
                                  +2
                                  startx == explorer.exe?
                                    0
                                    Что ж Вы не допереводили-то? :-)
                                      0
                                      Ни кто не в курсе, микрософты не обидят 32 бита вин 10?)
                                        0
                                        А зачем они вам?
                                          0
                                          на планшете вин10 32 бита и сменить на вин 10 64 пока не вышло, он просто не даёт
                                            0
                                            Думаю что в этом смысле они точно не обидят. Легаси для МС важен.
                                            0
                                            Вы не меня спрашивали, но попробую ответить.
                                            Тривиально: чтобы заводить lxss в вин10 на процессорах, которые не могут в 64 бита. Для «интернета вещей» и прочих мелкоконтроллерах

                                            Мне почему-то кажется, что вин7х64 для своей работы требует больше ресурсов, чем вин7х86. Соответственно, если запускать её виртуально, разница в быстродействии будет более заметна. Возможно, у вин10 тоже есть (если действительно есть) такой недостаток
                                            Я ничего не замерял и даже не гуглил по этой теме, чисто субъективное ощущение. Я даже не могу логически обосновать это, кроме как не совсем корректной обработкой системных вызовов в версии х64.
                                              0
                                              ситуация в том что проц то умеет 64, а вот уэфи туды запихнули с ограничением 32
                                                0
                                                Atom Z3735F в нём стоит если что
                                                  0
                                                  х64 хавает более оперативки, это факт и на пару процентов больше процессора. В основном такое дело из-за системы совместимости с х86.
                                                    0
                                                    х64 хватает 2-ух гигов, да и проц с подходящей же архитактурой
                                                      0
                                                      Не спорю. У меня тоже на двух гигах работает на ура, но кушает поболее чем х32. Я даже скажу так: У меня десятка х64 на 1 гигабайте живет
                                                        0
                                                        тогда по идее не должно быть особых проблем, но вот уэфи не даёт накатить х64
                                                0
                                                Вы собрались использовать Lxss.sys на Quark или Atom?
                                                  0
                                                  Atom
                                                    0
                                                    Atom Z3735F в нём стоит если что

                                                Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                                Самое читаемое