Запуск Wine в 32-разрядной песочнице на 64-разрядном NetBSD
Вольный перевод статьи: https://washbear.neocities.org/wine-sandbox.html
Disclaimer: это совершенно безумная наука и в основном учебное упражнение.
Недавно я обновил пакет Wine до последней стабильной версии и теперь хочу поиграть в некоторые старые игры Windows на NetBSD.
В текущем году моя машина работает под управлением amd64, и Wine необходимо построить с 32-разрядными библиотеками для работы с большим количеством старых приложений Windows.
«Mainline pkgsrc» пока не может делать странные мульти-архитектурные Wine сборки, поэтому 32-битная песочница кажется разумным способом использовать 32-битный Wine на amd64, не прибегая к запуску реальных Windows в NVMM. Посмотрим, была ли это жизнеспособной альтернативой варианту мульти-архитектурной поддержки в pkgsrc-wip...
Мы используем sandboxctl, который является удобным инструментом для быстрого перехода в другое пользовательское пространство NetBSD. Возможно, вы также не слишком доверяете приложениям Windows, которые вы запускаете - sandboxctl создает свежий образ системы, основанный на chroot - а chroot в NetBSD довольно защищен от бомб (оставил дословный перевод - так интереснее ;) ) https://github.com/earthquake/chw00t //очень интересная статья про безопасность и внутренности некоторых операционок. Переведу как будет время.
Я узнал немного больше о том, как работает X11, так же попробовав это, и это было приятно!
ТРЕБОВАНИЯ
Сначала установите пакет sandboxctl:
# pkgin install sandboxctl
Необходимо включить некоторые переменные sysctl.
Это позволит нескольким пользователям системы воспроизводить аудио и сохранит отладку, если вам интересно, почему вещи загадочно молчат:
# sysctl -w hw.audio0.multiuser=1
Этот разрешит Wine отобразить нулевую страницу (что ему необходимо сделать по проклятым причинам (забавное выражение;) ):
# sysctl -w vm.user_va0_disable=0
Добавьте их в файл /etc/sysctl.conf, чтобы сделать их постоянными.
Настройка sandboxctl
Скачайте некоторые NetBSD/i386 наборы в каталог:
$ mkdir -p ~/netbsd-i386/binary/sets && cd ~/netbsd-i386/binary/sets
$ ftp https://cdn.netbsd.org/pub/NetBSD/NetBSD-9.0/i386/binary/sets/base.tgz
$ ftp https://cdn.netbsd.org/pub/NetBSD/NetBSD-9.0/i386/binary/sets/etc.tgz
$ ftp https://cdn.netbsd.org/pub/NetBSD/NetBSD-9.0/i386/binary/sets/xbase.tgz
$ ftp https://cdn.netbsd.org/pub/NetBSD/NetBSD-9.0/i386/binary/sets/xetc.tgz
$ ftp https://cdn.netbsd.org/pub/NetBSD/NetBSD-9.0/i386/binary/sets/xfont.tgz
Создайте новый файл конфигурации для sandboxctl в /usr/pkg/etc/sandboxctl/wine.conf:
SANDBOX_TYPE=netbsd-release
SANDBOX_ROOT="/var/chroot/wine-i386"
NETBSD_RELEASE_RELEASEDIR="/home/washbear/netbsd-i386"
NETBSD_RELEASE_SETS="base etc xbase xetc xfont"
Давайте создадим песочницу (sandbox) и пользователя Wine:
# sandboxctl -c wine create
# sandboxctl -c wine run useradd -m -d /home/wine wine
Злоупотребление конфигурацией ядра
Wine должен злоупотреблять системой, потому что ему необходимо запускать приложения Windows. Вам нужно будет перенастроить NetBSD, чтобы разрешить это злоупотребление, потому что по умолчанию NetBSD довольно строга.
Если у вас запущен NetBSD 10 или -current? Тогда вам не нужно этого делать.
Запущен NetBSD 9.x? Убедитесь, что в вашем ядре отключены необходимые функции безопасности для запуска Wine. Вам понадобятся свежие исходники netbsd-9:
$ vi sys/arch/amd64/conf/GENERIC
Дело в этих параметрах:
# USER_LDT. Для его использования необходимо отключить SVS.
options USER_LDT # настраиваемый пользователем LDT; используется WINE
no options SVS
Создайте новое ядро. Не должно занимать слишком много времени :D
$ ./build.sh -U -j4 tools
$ ./build.sh -U -j4 kernel=GENERIC
Создайте резервную копию старого ядра, скопируйте новое на место и перезагрузитесь:
# mv /netbsd /onetbsd
# cp sys/arch/amd64/compile/obj/GENERIC/netbsd /netbsd
# shutdown -r now
Заставить X11 хорошо играть с песочницей (sandbox)
Нам нужен какой-то способ, разрешающий приложениям X11, помещенным в изолированную среду ( sandbox ) взаимодействовать с X-сервером.
Попытка 1 (X11-otherTCP)
X11 поверх TCP.
Это необходимо, если /tmp находится не в той же файловой системе, что и песочница. Мне потребовалось слишком много времени, чтобы осознать это.
Запустите X-сервер на хост-компьютере с TCP-соединениями и включенным непрямым (indirect glx) GLX:
$ startx -- -listen tcp +iglx
Как только вы окажетесь в X11, отключите контроль доступа, и, надеюсь, вы окажетесь либо за брандмауэром, либо в доверенной сети...
$ xhost +
Примечание:
xhost + Контроль доступа к X-серверу отключен; разрешение всем и отовсюду.
xhost - Контроль доступа к X-серверу включен; разрешение только по списку.
Попытка 2 (/tmp в той же файловой системе, что и sandbox)
Я отказался от TCP и удалил подключение tmpfs в /etc/fstab, чтобы /tmp мог находиться в той же файловой системе, что и песочница. Вообще-то мне это совсем не нравится.
Это позволяет использовать жесткие ссылки на Unix-сокеты X11 после запуска X:
# mkdir -m 777 -p /var/chroot/wine-i386/tmp/.X11-unix
# ln -f /tmp/.X11-unix/X0 /var/chroot/wine-i386/tmp/.X11-unix/X0
# chmod 777 /var/chroot/wine-i386/tmp/.X11-unix/X0
Затем используйте xauth, чтобы предоставить доступ к X-серверу вашего пользователя в sandbox:
$ xauth extract /var/chroot/wine-i386/home/wine/.Xauthority :0
OpenGL
Я быстро обнаружил, что Direct Rendering из 32-битной песочницы не так уж и жизнеспособен. В том смысле, что glxgears немедленно выполняет сегментацию ( segfaults ), независимо от того, осуществляется ли подключение к X11 через TCP или Unix сокет. Честно говоря, мне интересно, почему; но дальнейшая отладка этого, вероятно, слишком сложна для сегодняшнего дня.
Итак:
$ export LIBGL_ALWAYS_SOFTWARE=1
(Заставляет OpenGL использовать llvmpipe вместо графического процессора, может быть медленным в зависимости от возраста программного обеспечения и вашего оборудования. Для этого вам не нужен +iglx.
llvmpipe на удивление хорош даже на моем 5-летнем процессоре.)
или:
$ export LIBGL_ALWAYS_INDIRECT=1
(Кажется, работает недолго, но затем мой X-сервер выходит из строя - ymmv.)
Справочная страница Xserver(1) содержит несколько интересных сведений о +iglx и LIBGL_ALWAYS_INDIRECT=1...
Цитата:
Непрямой GLX (Indirect GLX) имеет ограниченное применение, так как ему не хватает поддержки многих современных функций и расширений OpenGL; это медленнее, чем прямые контексты (direct contexts); и открывает большую поверхность атаки для анализа ошибок протокола.
Охх...
Использование sandbox
shell в вашу песочницу:
# sandboxctl -c wine shell
Установите пакет Wine и любые другие, которые вы пожелаете, в вашей 32-разрядной песочнице:
# export PKG_PATH=http://cdn.netbsd.org/pub/pkgsrc/packages/NetBSD/i386/9.0/All(Я предпочитаю всегда использовать pkgin даже для таких простых случаев, как этот, это просто лучше.)
# pkg_add pkgin
# pkgin update
# pkgin install wine
su в свою учетную запись(войти root'ом):
# su -l wine
Снаружи песочницы, скопируйте некоторые файлы, может быть. В этом примере я копирую DRM-бесплатную версию Red Faction без DRM с GOG.com:
# cp ~/Downloads/setup_red_faction_2.0.0.7.exe /var/chroot/wine-i386/home/wine/
Внутри песочницы теперь я могу запустить свой 32-разрядный исполняемый файл:
$ export DISPLAY=:0
$ winecfg
$ wine setup_red_faction_2.0.0.7.exe
Когда вы закончите, выйдите из песочницы с помощью ^D ( CTRL+D )
Выводы
- Вся концепция запуска приложений Windows в Unix в некоторой степени проклята и требует некоторых компромиссов в области безопасности, чтобы упростить ее. Если вы заботитесь о том, чтобы ваша система Unix была защищена, возможно, установите Windows на другой машине - и не подпускайте ее близко к кабелю Ethernet.
- Такого рода "песочница" действительно хороша для разработки, тестирования и изоляции приложений, но сопровождается сильными звездочками, когда дело доходит до графики.
- Вероятно, мне следует поработать над интеграцией исправлений сборки Wine вместо того, чтобы тратить на это больше времени.
- На самом деле я предпочитаю запускать игры без DRM, используя compat_linux, когда могу. Это гораздо менее нервно.
Предостережения
Убедившись, что у пользователя песочницы тот же uid, что и у вашей обычной учетной записи пользователя, вероятно, поможет решить проблему с разрешениями.
В моем случае это был первый обычный пользователь, созданный в обеих системах, так что это было автоматически.