Ядро 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 и хочет запустить с будущей версией ядра. Посмотрим, но удивительно, что на критику этого грязного кода ушло три года.
Исследователь безопасности 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 и хочет запустить с будущей версией ядра. Посмотрим, но удивительно, что на критику этого грязного кода ушло три года.
Похожие публикации
Нет комментариев