Інтерв'ю з Matthieu Herrb: тестування сервера X.Org

Цього року Xorg, вільної реалізації X Window System, виповнюється 30 років. Незважаючи на існування і розвиток альтернатив Xorg залишається живішим за всіх живих.

З нагоди ювілею я поставив кілька запитань людині, яка 23 (!) роки працює над розвитком цього проекту. Звати його Matthieu Herrb. Крім своєї участі в проекті X.Org він також стоїть біля витоків створення окремої версії Xorg для проекту OpenBSD - Xenocara.

X.Org це великий і складний проект. Як виглядає процес розробки?

Проект не такий великий, порівняно з іншими проектами, на зразок Firefox, Chrome або навіть Gnome або KDE.

Процес розробки трохи відрізняється для різних компонентів, що активно розробляються (X сервер, трохи бібліотек і драйвера) і застарілі компоненти, на зразок libXt і всі програми, засновані на цій бібліотеці.

Також є постійна взаємодія між двома групами: це розробники Mesa і DRM модулів в Linux ядрі.

Ідеї обговорюються під час зустрічей розробників (один раз на рік, в Європі або Північній Америці, наступний буде у вересні цього року в Бордо, Франція) або в поштовому списку розсилки xorg-devel.

Останні кілька років ми адаптували модель розробки, яка дуже схожа на модель розробки Linux ядра: патчі (сформовані за допомогою git ceat-patch) посилаються в список розсилки для рев'ю, проводиться обговорення і, якщо досягнута домовленість в обговоренні, то патч коміттиться мейнтейнером.

Існує один мейнтейнер для X сервера (зараз це Кейт Пакард). Для інших компонентів прийом коммітів більш простий і як правило автору патчу достатньо його запропонувати один раз, щоб рев'ю пройшло успішно.

І, щоб бути повним, в даний час розвиток популярних драйверів майже повністю покладено на компанії (Intel, AMD, VMWare), так що інженери з цих компаній роблять більшість змін.

Скільки розробників залучено в процес розробки?

Якщо рахувати розробників Mesa, графічний стек в ядрі Linux і розробників X сервера, то це близько 50-60 осіб хто коміттить на постійній основі в один з репозиторіїв.

Як виглядає процес тестування? Ви використовуєте регулярне тестування (запуск тестів на кожен коміт) чи це нерегулярне тестування?

У нас є кілька інструментів для постійного, автоматизованого тестування, але вони не ефективні настільки наскільки нам хотілося б.

Які інструменти, тести і тестові фреймворки ви використовуєте? Я знайшов багато тестів (наприклад XTS, rendercheck, glean, piglit тощо) в репозиторії (http://cgit.freedesktop.org/), але багато хто з них виглядає застарілими. Чи створюють розробники тести на регулярній основі для нового функціоналу і на основі багфіксів?

До того ж до всіх цих існуючих тестсьютів, які зазвичай дуже громіздкі для використання на регулярній основі, Peter Hutterer розробив відносно новий, інтеграційний тестсьют для X сервера, який передбачається запускати автоматично з білдової системи X сервера (за допомогою'make test') і на нашому сервері з Tinderbox. Скрипт build.sh використовуваний багатьма розробниками, також запускає ці тести за замовчуванням.

Але враховуючи величезний спектр підтримуваних систем (хоча з часу перемикання з XFree86 на X.Org це число постійно скорочується) тільки невелика частина з них отримує фактичне регулярне тестування.

Більшість тестів зроблено людьми, які інтегрують X.Org в інші системи і дистрибутиви.

Це мій випадок серед інших. Я підтримую X.Org в OpenBSD (і допомагав у NetBSD раніше), так що я тестую конфігурації, які не охоплюються основними розробниками X сервера і часто знаходжу помилки, які пропускаються в процесі тестування, або тому, що вони специфічні для платформи (наприклад, OpenBSD є однією з декількох систем, які як і раніше працюють на деяких екзотичних архітектурах, таких як VAX, m88k або навіть sparc32), або просто тому, що наша реалізація malloc () здатна зловити помилки, які вислизають від інших інструментів використовуваних в Linux.

Які види тестування використовуються (тестування продуктивності, функціональне, тестування на сумісність, тестування стабільності, юніт тестування тощо)?

Новий тестовий фреймворк для X сервера в основному використовує юніт-тестування та функціональне тестування, щоб переконатися, що компоненти X сервера працюють так, як передбачається, незалежно від драйвера.

У разі використання тестів ви вимірюєте покриття коду тестами?

Ні. Так як найчастіше код і тести пише один і той же чоловік, то він має деяке розуміння про покриття цього коду,

але немає якогось формального інструменту для вимірювання покриття.

Як часто ви тестуєте: час від часу чи на регулярній основі?

Платформа Tinderbox передбачалася для запуску тестів настільки часто як це можливо, але більшість інших тестів запускаються вручну час від часу.

Як тестуються нові фічі?

Нові можливості в X, ти жартуєш, так? А якщо серйозно, то було додано деяку кількість нових фіч в основному в Mesa (OpenGL) код і драйвер вводу. Або нові тести для фіч додаються до тестування одночасно із самим кодом, або, у випадку з OpenGL, використовуються зовнішні перевірки відповідності.

Ви використовуєте Continuous Integration у процесі розробки?

Так, я згадав вже кілька разів Tinderbox, хоча це далеко від досконалості.

Який інструмент ви використовуєте для роботи з дефектами? Хто відповідальний за роботу з багами?

У нас є Bugzilla, доповнена системою відстеження патчів (patchwork) яка відстежує, що не залишилося незакомічених патчів that no submitted patch gets forgotten or unhandled.

Іноді в X.Org знаходять проблеми пов'язані з безпекою (http://www.x.org/wiki/Development/Security/). Ви використовуєте регулярний аудит коду?

І та й ні:Наскільки я знаю X.Org не має виділеної людини для аудиту на регулярній основі. Але деякі дистрибутиви (наприклад Oracle/Solaris в особі Alan Coopersmith) регулярно використовують інструменти орієнтовані на виявлення проблем з безпекою і вносять виправлення в проект. Іноді, коли з'являється конкретний новий вид вразливості (як наприклад форматування рядків або цілочисельного переповнення близько 10 років тому), то ми робимо величезний чистку існуючого коду, щоб спробувати все в ньому виправити.

Ми також отримуємо зовнішню допомогу від незалежних дослідників у сфері безпеки, які стежать за цікавими вразливостями, і оскільки X-сервер все ще запускається з правами суперкористувача на багатьох системах, це все ще виправдано.

Останній рік Ilja Van Sprundel відрепортував дуже велику кількість вразливостей в бібіліотеках X сервера і в самому X сервері, в основному стосуються відсутністю хорошої валідації повідомлень в протоколі X сервера.

Ви застосовуєте статичний аналіз коду?

Відповідь схожа на мій попередній. Tinderbox не запускає жодні статичні аналізатори крім gcc з опцією -Wall і ще деяких додаткових опцій. Але у деяких розробників (включаючи Алана з Oracle) є доступ до потужних статичних аналізаторів коду і вони запускають їх час від часу.

Coverity має програму для проведення статичного аналізу вільних огранізаціях. X.Org був частиною цієї програми і вони допомогли нам знайти ряд проблем.

X.Org підтримує все більш менш популярні операційні системи: Linux, FreeBSD, NetBSD, OpenBSD, Solaris, Microsoft Windows. Як ви забезпечуєте впевненість у стабільній роботі на всіх цих ОС?

Як я пояснив вище це забезпечується волонтерами (або оплачуваними працівниками в деяких випадках) з різних проектів. Більшість розробників фокусується на Linux, який став основною платформою розробки в останні 10 років. Але від себе хочу додати, що мені трохи шкода, що розробники не втручаються трохи більше на підтримку на інших системах. З мого досвіду потрібно багато вивчити для розробки на більш ніж одній платформі і з точки зору безпеки коду різноманітність має велике значення (навіть якщо це збільшує вартість розробки).

Хто відповідальний за випуск нових версій? Які критерії для релізу?

Існує мейнтейнер для X сервера, який відповідальний за випуск релізу. В даний момент ми працюємо в 6-тимісячному циклі розробки для випуску нового релізу кожні 6 місяців. Попередній реліз отримує -stable мейнтейнера і в основному підтримується протягом більше 12 місяців.

На додаток до релізів X Server ми досі випускаємо релізи «Katamari» з повним послідовним набором бібліотек і утиліт на додаток до X-серверу. Це робиться один або кілька разів на рік. (поточним релізом «Katamari» є 7.7, на основі X сервера 1.14). Але потреба в релізах «Katamari» часто ставиться під сумнів, оскільки виробники дистрибутивів, як правило, підтримують свої власні «Katamari» (з великою кількістю мержів з upstream), незалежно від офіційних, що випускаються X.Org.

Часи, коли проект XFree86 надавав бінарні збірки для більшість підтримуваних систем (від SVR4 до Linux, включаючи NetBSD, OS/2 і кілька інших), безумовно, закінчилися.

Розкажіть про найцікавіший бага у вашій практиці:)

Робота з кодом, який був спроектований і реалізований коли безпека коду не мала великого значення, не так вже й цікава. X сервер був спочатку permissive system (пам'ятаєте «xhost +»?). Люди не дбали про переповнення буфера або інших зловмисних шляхах експлуатації помилок кодування. Фічі на зразок розширення X-SHM були зламані спочатку. (SHM було виправлено шляхом використання нового API, заснованого на передачі файлового дескриптора).

Але найбільш цікава проблема, з моєї точки зору, описана в статті Loic Dufflot на CanSecWest 2006, де він пояснив, що навіть з privelege escalation, який я додав в OpenBSD, залишається можливість «простого» впровадження коду для отримання контролю над ядром ОС через те, що X сервер має прямий доступ до заліза.

Це те, що завжди було відомо (і я навіть говорив про це в своїй доповіді на RMLL в 2003 році), але відсутність реалізації PoC (Proof of Concept) дозволяє багатьом розробникам ігнорувати проблему.

Спасибі за відповіді і бажаю вам менше багів в коді!

Дякую.

На закінчення хочу додати, що так, X.Org далекий від ідеалу з точки зору тестування. Ми намагаємося робити його кращим, але це не найпривабливіша область для контриб'юторів, речі не робляться швидко, так як більшість розробників воліють більш привабливі речі.