На прошлой неделе была конференция для Linux Plumbers и там бы | Протестировал

На прошлой неделе была конференция для Linux Plumbers и там была традиционная секция "Testing & Fuzzing".

Доклады (по ссылкам слайды в PDF):

- Detecting semantic bugs in the Linux kernel using differential fuzzing

Доклад разработчика фаззера syzcaller про syz-verifier. Автор выделяет отдельный класс багов, которые не вызывают сбой в системе, но в то же время приводят к некорректному поведению системы. Он называет такие баги семантическими. В слайдах он рассуждает про отсутствие спецификации для ядра Linux и говорит, что specification = documentation + man pages + implied expectations of user programs. (Ну да, когда оно десятилетиями как-то разрабатывается без требований и спецификации, то если документация хорошая, то она становится спецификацией. Или иногда тесты в такой роли выступают.) Если я правильно понял, что он предлагает с помощью syz-verifier более функциональное тестирование делать и более близкое к системным требованиям к системе. А схема предлагается следующая: запускать фаззинг на двух версиях реализации и сравнивать результат, если отличается, то баг. Кстати подход differential testing, про который в докладе рассказывают, был впервые изложен в 2007 году, хотя идея то вроде простая. Даже подход с property-based testing и того раньше появился.

- Bare-metal testing using containerised test suites

Есть класс тестов, которые надо запускать на голом железе. Чтобы это делать тест и его зависимости зашивают в rootfs, автор рассказывает про инструменты для создания rootfs. Потом автор выдвигает идею: если тесты уже запускаются в контейнерах, то почему ты не использовать образ для этих контейнеров для запуска на baremetal. Дальше идёт рассказ boot2container.

- Common Test Report Database (KCIDB)

Про систему для тестирования изменений в основную ветку ядра Linux я уже писал. Доклад от одного из разработчиков. Там много не очень интересных деталей, но стоит посмотреть как сейчас выглядит морда для этой штуки - https://datawarehouse.cki-project.org/confidence/tests. Впечатляет.

- Testing the Red-Black tree implementation of the Linux kernel against a formally verified variant

Есть такой подход, когда модель системы описывают в виде доказанных теорем в интерактивном прувере и получают верифицированную модель системы. Потом эту верифицированную модель используют для генерации тестов для тестируемой реализации. На самом деле очень интересный подход, но сложный в реализации, не удивительно, что не сильно популярный. В докладе речь про использование модели Red-Black Tree, верифицированной в прувере Isabelle, в качестве оракула в теста для реализации RBT в ядре Linux. Работу делал бакалавр немецкого университета.

- Слайды Fuzzing Device Interfaces of Protected Virtual Machines и Testing in-kernel Rust code мне показались непонятными, основную идею не ухватил.

- KUnit: New Features and New Growth Рассказ про KUnit - фреймворк для написания юнит-тестов для ядра Linux. Количество тестов понемногу растёт и достигло порядка 300 тестов. Проблемы для написания юнит-тестов в ядре: сильно связанный код, нельзя тестировать в изоляции от другого кода; архитектурно-зависимый код. Докладчик рассказывает, что сделали в KUnit: сделали поддержку запуска тестов в QEMU, сделали возможность пропускать тесты (aka SKIP), возможность указания тестовых параметров в .kunitconfig, возможность выбора тестов для запуска, статистика запущенных тестов и т.д. И KUnit и kselftests используют варианты формата TAP (Test Anything Protocol) для репорта результатов тестирования. Самый старый формат для тестовых отчётов!