Ядро Linux заставляло процессы, начинающиеся с «X», вести себя иначе

Обнаружен уродливый взлом ядра Linux, который использовался в основной ветке более трех лет. Из-за ошибочного X.Org Server / xf86-video-modesetting DDX ядро Linux навязывает различное поведение в зависимости от того, начинается ли процесс с «X», и, в свою очередь, отключает поддержку настройки атомарного режима.

Исследователь безопасности Linux Джейсон Доненфельд (который также известен тем, что придумал WireGuard), наткнулся на этот уродливый взлом кода в ядре.


На этих выходных Доненфельд прокомментировал список рассылки ядра:
Это возвращает 26b1d3b527e7 («drm/atomic: забери атомные игрушки у X»), похожий на руткит кладж, которому нечего делать внутри ядра общего назначения. Это тип отладочного хака, который я буду использовать на мгновение, но никогда не зафиксирую, или что-то вроде трюка с вредоносной программой, скрывающей процесс сначала.

Предыстория заключается в том, что некоторый код пользовательского пространства — xorg-server — имеет DDX для настройки режима, который на самом деле закодирован неправильно. Поскольку никто больше не хотел поддерживать X11, а не исправлять ошибочный код, ядро ​​было скорректировано, чтобы не касаться X11. Облом, но достаточно справедливо: если ядро ​​​​не хочет больше поддерживать какой-либо API пользовательского пространства, правильно будет организовать изящный откат, когда пользовательское пространство считает, что оно недоступно управляемым способом.

Тем не менее, *способ* сделать это — просто проверить `current->comm[0] == 'X'` и отключить его только в этом случае. Таким образом, это означает, что дело *не* просто в том, что ядро ​​больше не хочет поддерживать конкретный API пользовательского пространства, а скорее в том, что ядро ​​не хочет поддерживать xorg-server, теоретически, но на самом деле, оказывается, это все процессы, которые начинаться с «Х».

Играть в игры с current->comm, как это, очевидно, неправильно, и это довольно шокирует, что это когда-либо было зафиксировано.

Фиксация этого ядра с проверкой первого символа «X» была сделана еще в сентябре 2019 года. Аргумент в этой фиксации ядра Linux в то время был следующим:
В -modesetting ddx полностью нарушено представление о том, как работает атомарность:
— не отключает старые соединители, при условии, что они автоматически отключаются, как в устаревшем setcrtc
— предполагается, что ASYNC_FLIP подключен для атомарного ioctl
— ни одного обращения к TEST_ONLY

[Другими словами] реализация представляет собой перевод 1:1 устаревших ioctl на атомарные, что а) не работает, б) бессмысленно.

У нас уже есть ошибки как в i915, так и в amdgpu-DC, из-за которых мы не можем включить удобные функции.

Если кого-то когда-нибудь волнует атомарный уровень в X, мы можем легко добавить новый атомный уровень (req->value == 2), чтобы X вернул себе блестящие игрушки.

Поскольку эти неработающие версии -modesetting уже поставляются, нет другого способа выйти из этой ситуации.

«Хорошая» новость заключается в том, что с тех пор на стороне пользовательского пространства еще в 2019 году код xf86-video-modesetting по умолчанию отключил атомарную поддержку. Так что технически, если в течение последних трех лет запускался обновленный стек X.Org, этот взлом ядра больше не нужен, поскольку пользовательское пространство просто избегает атомарного API.

Посмотрим, согласен ли Линус Торвальдс с удалением этого хака, поскольку, в конце концов, он противоречит его принципу «не нарушать пользовательское пространство», а затем регрессирует систему, если он придерживается устаревшего стека X.Org Server и хочет запустить с будущей версией ядра. Посмотрим, но удивительно, что на критику этого грязного кода ушло три года.
Поделиться:

Похожие публикации

Тут ничего нет

Нет комментариев