21 Ноября 2024, 21:22

X.Org

Автор turbo, 05 Августа 2008, 20:26

« предыдущая тема - следующая тема »

0 Пользователей и 1 Гость просматривают эту тему.

Zhek@Ch

15 Февраля 2011, 10:43 #20 Последнее редактирование: 15 Февраля 2011, 10:44 от Zhek@Ch
[size="3"]Для драйвера xf86-video-v4l обеспечена поддержка Video For Linux 2 [/size]

Для xorg-драйвера xf86-video-v4l представлен патч, переводящий драйвер с программного интерфейса для организации захвата видео V4L1 (Video For Linux) на современный вариант API V4L2, поддерживаемый Linux-ядрами серии 2.6.x. В ядре 2.6.38 запланировано прекращение поддержки V4L1, что приведет к неработоспособности xf86-video-v4l. В настоящее время первой версии интерфейса V4L в ядре Linux присвоен статус устаревшей и по-умолчанию эта функция выключена, но в новой реализации V4L2 предусмотрен режим совместимости с V4L1 для старых приложений. Через него и работает xf86-video-v4l сегодня в большинстве популярных дистрибутивов, обычно вместе с приложением должна быть подгружена специальная библиотека. V4L - это драйвер, который используется множеством устройств для захвата видео, например, веб-камерами и TV-тюнерами. Первая версия появилась в ядре Linux 2.2, для ветки 2.6 была разработана вторая версия интерфейса, после чего был выпущен специальный драйвер xf86-video-v4l2. Несмотря на это, старый драйвер xf86-video-v4l до сих пор используется многими приложениями, в которых не осуществлён переход на API V4L 2. Хотя его код не обновлялся с июня 2010 года, проект считается активным.

Сотрудник компании Red Hat, Mauro Carvalho Chehab, несколько дней назад представил для xf86-video-v4l большой патч, который переводит xf86-video-v4l на использование V4L2. Mauro пишет о том, что "большая часть работы сделана", тем не менее патч еще не обеспечивает работу со всеми драйверами V4L2, поддержку которых планируется добавить в ближайшем будущем. В дальнейшем Mauro собирается перевести некоторые компоненты xf86-video-v4l, использующие устаревшие функции Xv, на современную функцию текстурированного видео (Textured Video). Это позволит заработать остальным драйверам для V4L2.

Что это даёт приложениям? В большинстве дистрибутивов Linux ядро собрано без поддержки V4L1, но с параметром обратной совместимости в V4L2. Некоторые приложения для Linux используют xf86-video-v4l для работы с веб-камерами, например Skype и Kopete из состава KDE 3. Поэтому если у пользователя веб-камера с драйвером для V4L2, в некоторых случаях запускать эти приложения нужно с особыми параметрами. Теперь, когда xf86-video-v4l сам работает с V4L2, владельцам веб-камер с драйверами, базирующимися на V4L1, не придется прибегать к дополнительным манипуляциям.


Zhek@Ch

03 Марта 2011, 11:49 #21 Последнее редактирование: 03 Марта 2011, 12:52 от Zhek@Ch
[size="3"]Релиз X.Org Server 1.10. Компания AMD открыла код, связанный с API XvBA [/size]

Анонсирован релиз X.Org Server 1.10 в котором внесено более 700 изменений, главным образом связанных с исправлением ошибок и мелкими правками. Значительных улучшений в новой версии почти нет. К сожалению в последний момент в релиз не был включён код RandR 1.4, обеспечивающий поддержку привязки пиксельных карт (pixmap) к отдельным CRTC-видеоконтроллерам. Также в состав нового релиза не вошел X Input 2.1, в котором планировалось реализовать программный интерфейс для работы с устройствами ввода, поддерживающими одновременные касания (мультитач).

Из улучшений можно отметить интеграцию кода новой улучшенной подсистемы синхронизации X Synchronization Fences, разработанной компанией NVIDIA и позволяющей организовать синхронизацию формирования вывода на базе протокола X11 с клиентами, поддерживающими прямой рендеринг (DRI), такими как OpenGL. В частности, X Synchronization Fences можно использовать для синхронизации обновлений экрана в базирующихся на OpenGL композитных менеджерах со стандартным рендерингом X-сервера (сейчас в композитных менеджерах для совмещения X11-вывода с итоговым изображением приходится использовать двойную буферизацию).

Дополнительно можно отметить публикацию компанией AMD исходных текстов SDK и набора утилит для использования в Linux-приложениях нового API XvBA (X-Video Bitstream Acceleration) для задействования функций акселерации кодирования и декодирования видео. В состав пакета входят необходимые заголовочные файлы, документация (ранее API был недокументирован), сопутствующие пользовательские библиотеки (libxvbat) и набор примеров. Также подготовлено несколько полезных утилит, таких как xvbainfo для оценки степени поддержки XvBA, xvba для трассировки вызова XvBA API и xvbaplay с реализацией простого медиа-плеера.

Для акселерации декодирования видео в XvBA используется UVD2-движок современных GPU AMD/ATI. XvBA дополнят собой два других API для доступа к функциям декодирования видео - VDPAU и VA-API, продвигаемых компаниями NVIDIA и Intel. Примечательно, что API XvBA был создан уже достаточно давно, но не выпускался наружу - для пользователей в драйвере Catalyst был доступен VA-API-фродтэнд, работающий поверх XvBA.

К сожалению, непосредственно спецификации движка UVD2 остаются закрытыми и их публикации мешают требования DRM (Digital Rights Management), что затрудняет обеспечение реализации поддержки XvBA в открытых видеодрайверах. Тем не менее, при работе проприетарного драйвера Catalyst, опубликованный SDK позволяет использовать в различных приложениях функции XvBA для прямого обращения к движку UVD2, минуя промежуточную прослойку VA-API. Наличие VA-API-фронтэнда ставит под сомнение целесообразность добавления поддержки XvBA в пользовательские приложения, поэтому можно предположить, что в скором времени поддержка VA-API в Catalyst будет прекращена.

# opennet.ru

[size="3"]Оценка вклада участников разработки X Server 1.10 [/size]

Тьяго Виньятти (Tiago Vignatti), работающий в компании Nokia и занимающийся поддержкой пакета с X.Org-сервером для платформы MeeGo, опубликовал статистику степени участия различных людей и компаний, внесших свой вклад в разработку X.Org Server 1.10 и параллельно развиваемой с X-сервером инфраструктуры.

Некоторые факты:

  • В процессе подготовки релиза в репозитории xserver, proto, lib и xcb внесено 1258 наборов изменений от 93 разработчиков, из которых 70 разработчиков являются сотрудниками тех или иных компаний. В сумме патч содержит 139275 новых строк кода и 58982 удаленных строк;
  • Рейтинги компаний по числу добавленных в X-сервер наборов изменений:
    • Oracle 244 (19.4%)
    • Red Hat 225 (17.9%)
    • Nokia 122 (9.7%)
    • Intel 46 (3.7%)
    • NVidia 30 (2.4%)
    • Apple 36 (2.9%)
  • Рейтинги компаний по числу измененных строк кода:
    • Apple 27540 (17.0%)
    • Oracle 14567 (9.0%)
    • Red Hat 8089 (5.0%)
    • Intel 4574 (2.8%)
    • Nokia 3153 (1.9%)
  • Рейтинги компаний по числу вовлеченных в процесс разработчиков:
    • Red Hat 8 (8.3%)
    • Nokia 8 (8.3%)
    • Intel 7 (7.3%)
    • Canonical 3 (3.1%)
    • VMWare 3 (3.1%)
    • Oracle 2 (2.1%)
    • NVidia 2 (2.1%)
    • Apple 1 (1.0%)
  • Разработчиком, добавившим наибольшее количество патчей (19.3%), стал Алан Куперсмит (Alan Coopersmith), работник Oracle. На втором месте Гаэтан Надон (Gaetan Nadon) - 15.3%, на третьем Питер Хаттерер (Peter Hutterer) - 9.6%.
  • При оценке числа измененных строк кода лидирует Мэтт Дью (Matt Dew) - 35.7%. На втором месте Джереми Хаддлестон (Jeremy Huddleston) - 15.4%, на третьем - Фернандо Кариджо (Fernando Carrijo) - 10.3%;
  • Наиболее активным разработчиком подсистем ввода (xf86-input-*, xkbcomp, xkeyboard-config) по числу добавленных патчей признан Питер Хаттерер (Peter Hutterer) - 51.9%, на втором месте Сергей Удальцов - 10.9%, на третьем месте Александр Шадчин - 7.2%. По числу измененных строк кода на первом месте Сергей Удальцов - 79.0%, на втором месте Питер Хаттерер (8.8%) и на третьем - Александр Шадчин (3.3%);
  • 52.9% всех наборов изменений в подсистеме ввода сделано работниками Red Hat, 6.1% - Oracle, 2% - Canonical и 1% - VMWare.
  • В разработке libdrm, Mesa и драйверов xf86-video-* принял участие 131 разработчик. Наиболее объёмный вклад внёс, Брайан Пол (Brian Paul), который добавил 11.1% от всех патчей и внес 13.0% всех изменений. Брайан Пол является создателем Mesa и работает в настоящее время в компании VMware.
  • Рейтинг компаний, внесших наиболее значительный вклад в разработку libdrm, Mesa и драйверов xf86-video-*.
    • По числу патчей:
      • VMWare 1582 (30.3%)
      • Intel 1292 (24.7%)
      • Red Hat 546 (10.5%)
      • LunarG 252 (4.8%)
      • AMD 156 (3.0%)
    • По объему изменений:
      • Intel 132677 (24.5%)
      • VMWare 105087 (19.4%)
      • Red Hat 87373 (16.1%)
      • LunarG 38973 (7.2%)
      • AMD 19690 (3.6%)
Будучи работником Nokia, Тьяго Виньятти упомянул о своем отношении к партнерству Nokia и Microsoft. По словам Тьяго он глубоко шокирован произошедшим, но уверен, что развитие MeeGo будет продолжено, хотя вклад Nokia в разработку X11 очевидно будет уменьшаться со временем. Группа по развитию графической системы только начала ощущать на себе первые результаты новой корпоративной культуры, позволяющей продвигать все что можно в upstream, но сейчас эта практика на грани развала.

Rubik

[size="3"]Локальная Root-уязвимость в X.Org[/size]

Разработчики проекта X.Org объявили об обнаружении критической уязвимости в утилите xrdb, позволяющей локальному злоумышленнику выполнить свой код с привилегиями суперпользователя. Организация запуска кода производится через передачу специально оформленного имени хоста, содержащего экранированные спецсимволы. Выполнение кода производится в момент запуска дисплейного менеджера, в котором для загрузки базы ресурсов от имени суперпользователя используется утилита xrdb.

Проблемное имя хоста может быть передано двумя путями: через DHCP или xdmcp. В первом случае злоумышленник должен иметь административный доступ к DHCP-серверу или физический доступ к локальному сегменту сети. Во втором случае на атакуемой системе должна присутствовать возможность удаленного входа по xdmcp и злоумышленник должен иметь локальный аккаунт в системе.

Проблему обнаружил Себастьян Крамер (Sebastian Krahmer) из команды по обеспечению безопасности SUSE Linux. Уязвимость исправлена в xrdb 1.0.9 (в состав последнего релиза X11R7.6 по прежнему входит уязвимая версия xrdb 1.0.7). Обновления с исправлением уязвимости пока недоступны для дистрибутивов, статус выхода исправлений можно отследить на следующих страницах: Slackware, Gentoo, Mandriva, openSUSE, CentOS, Fedora, RHEL, Debian, Ubuntu, FreeBSD.


Zhek@Ch

07 Мая 2011, 08:29 #23 Последнее редактирование: 07 Мая 2011, 08:29 от Zhek@Ch
[size="3"]xf86-video-nested - драйвер для организации вложенного запуска X-серверов [/size]

В списке рассылки разработчиков X.Org представлен новый драйвер xf86-video-nested, позволяющий поверх уже работающего X-сервера запустить в окне еще один X-сервер. Уровень вложенности может быть любой. Также поддерживается запуск разных версий X-сервера в разных окнах.


Zhek@Ch

11 Июня 2011, 01:04 #24 Последнее редактирование: 11 Июня 2011, 01:05 от Zhek@Ch
[size="3"]Для X.Org-драйвера Synaptics представлена поддержка плавной прокрутки и прогнозирования движения[/size]

В списке рассылки разработчиков X.Org представлен набор патчей для драйвера xf86-input-synaptics с реализацией ряда технологий, разработанных для операционной системы ChromiumOS. В частности патчи позволяют использовать на тачпадах Synaptics режим плавной прокрутки, улучшенные механизмы акселерации и методы прогнозирования движения, позволяющие игнорировать случайные перемещения и более точно отслеживать управляющие прикосновения.

Несколькими днями раньше был представлен аналогичный набор патчей с результатами работы по чистке кода подсистемы ввода X.Org-сервера и реализации возможности использования плавной прокрутки. Ожидается, что опубликованные патчи будут включены в состав X-сервера 1.12.


Zhek@Ch

18 Октября 2011, 22:13 #25 Последнее редактирование: 18 Октября 2011, 22:14 от Zhek@Ch
[size="3"]Графическая система X12 начинает обретать форму [/size]

Разработчики проекта X.Org не теряют надежду создать X12, улучшенную реализацию протокола, идущую на смену X11. На днях, один из разработчиков проекта, спустя почти полтора года с момента прошлой правки, заметно обновил wiki-страницу с планом развития проекта.

В плане признаётся, что с момента создания X11 в 1990-х годах техника значительно продвинулась вперёд и компьютеры изменились до неузнаваемости. Вместо простой модели работы через framebuffer теперь повсеместно используются программируемые графические процессоры, усложнённые и функциональные. Расширился спектр потребительских платформ, кроме настольных систем и ноутбуков, появились новые классы устройств - нетбуки, планшеты, телеприставки и смартфоны. Многоядерные процессоры, позволяющие выполнять операции в параллельном режиме, плотно вошли в обиход и уже давно не являются атрибутами суперкомпьютеров. Все это говорит о том, что X11 был разработан для другой эры развития компьютерной техники и требует переработки.

Среди указанных в плане требований:

  • Сохранение принципа сетевой прозрачности, при котором приложение может быть выполнено удалённо без использования каких либо специальных функций и без оглядки на то, где именно и на каких типах устройств вывода оно будет использовано;
  • Пересмотр и переработка с нуля механизмов обеспечения безопасности. Разработка с оглядкой на безопасность;
  • Поддержка различных типов платформ - от мобильных телефонов до планшетов и настольных систем;
  • Поддержка современных графических адаптеров и композитного режима. X12 должен обеспечить возможность полного доступа к оборудованию, не вынуждая работать в обход X, что наблюдается в настоящее время;
  • Продолжение предоставления возможности работы через Framebuffer;
  • Обеспечение максимально возможной эффективности протокола;
  • Многопоточная обработка данных, позволяющая повысить производительность на многоядерных системах.

Zhek@Ch

24 Октября 2011, 01:59 #26 Последнее редактирование: 28 Октября 2011, 11:22 от Zhek@Ch
[size="3"]Начальная реализация горячего подключения видеоадаптеров без перезапуска X-сервера [/size]

Дэвид Эирлай (David Airlie), работающий в компании Red Hat, представил результаты первых экспериментов по реализации режима горячего подключения видеодрайверов в X.org, позволяющего подключать дополнительные видеокарты без перезапуска X-сервера. На представленном демонстрационном видеоролике, к компьютеру через порт USB подключается внешний видеоадаптер DisplayLink, при этом на него сразу начинает транслироваться текущее содержимое экрана.

В конфигурации использован драйвер xf86-video-modesetting и модифицированный X-сервер, поддерживающий новый экспериментальный ABI для взаимодействия с драйверами. При запуске X-сервера драйвер загружается через udev, после чего для работы X-клиентов экспортируется экран Screen, к которому присоединяется представление низкоуровневого экрана DrvScreen1. После горячего подключения видеокарты создаётся ещё один низкоуровневый экран DrvScreen2, связанный с новым драйвером, который также подключается к общему экрану Screen, работающему через стандартный протокол X11. Вся экранная активность, связанная со взаимодействием Screen и прослойкой драйверов, дублируется для всех низкоуровневых экранов (DrvScreen1 и DrvScreen2). Таким образом единый X11 экран Screen выступает в роли надстройки, занимающейся мультиплексированием вывода для экранов DrvScreen.

Технология отличается от Xinerama тем, что дублирование операций производится не на уровне протокола X11, а на более низком уровне взаимодействия с оборудованием. При этом изменение кода рендеринга даёт возможность не заботиться о том, с какого GPU сформирован вывод, т.е. можно выполнять все ресурсоёмкие операции на GPU основной карты и затем просто транслировать получившееся изображение на маломощную внешнюю карту (без необходимости повторного рендеринга на этой карте). Разработка пока находится на ранней стадии, по словам Дэвида Эирлая он лишь увидел небольшой свет в конце туннеля. Тем не менее, это первый видимый результат после года работы над решением данной задачи. В дальнейшем планируется реализовать поддержку добавления и удаления DrvScreen, а также возможность динамического переключения GPU.


Zhek@Ch

28 Октября 2011, 11:25 #27 Последнее редактирование: 28 Октября 2011, 11:25 от Zhek@Ch
[size="3"]Локальная уязвимость в X.Org [/size]

В X.Org найдена опасная уязвимость, позволяющая путем манипуляции на этапе создания lock-файла поменять права доступа к любому файлу в системе на 444 (полный доступ на чтение для всех). Например, локальный злоумышленник на этапе запуска X.Org-сервера может поменять права на файл /etc/shadow и получить доступ к хэшам паролей всех пользователей в системе, или поменять права на блочное устройство и прочитать полное содержимое дисковых разделов. Для успешной эксплуатации у атакующего должна быть возможность запуска X-сервера.

Техника эксплуатации уязвимости достаточно простая (готовый эксплоит приводится в тексте уведомления о наличии проблемы):

[list=1]
  • Создаётся фиктивная символическая ссылка "/tmp/.X1-lock" -> "/dontexist";
  • Запускается X-сервер;
  • Останавливается X-сервер через отправку процессу сигнала SIGSTOP сразу после создания "/tmp/.tX1-lock" (угадать нужный момент помогает эксплоит);
  • Запускается ещё один процесс X для удаления /tmp/.tX1-lock;
  • Создаётся символическая ссылка "/tmp/.tX1-lock" -> "/etc/shadow";
  • Отправляется SIGCONT остановленному на третьем шаге процессу, который выполняет вызов chmod() для подменённого файла;
В общем виде процесс эксплуатации выглядит примерно так:


$ ls -l /etc/shadow
-rw-r----- 1 root shadow 1072 Aug 7 07:10 /etc/shadow
$ ./xchmod
$ ls -l /etc/shadow
-r--r--r-- 1 root shadow 1072 Aug 7 07:10 /etc/shadow

Исправление пока доступно в виде патча для X Server 1.11.2 и экспериментальной ветки 1.12. Обновление пакетов с устранением уязвимости доступно для FreeBSD, Ubuntu и Gentoo. Неисправленной узявимость остаётся в Slackware, Mandriva, openSUSE, CentOS, Fedora, RHEL и Debian.