Протестировал

2021-04-29 16:52:42 Негативное тестирование с использованием fault-injection стало за последнее время очень популярным благодаря подходу Chaos Engineering. После того, как Netflix опубликовала код chaosmonkey появилось какое-то невероятное количество открытых проектов с которыми можно этот самый chaos engineering устроить для вашего продукта. Даже у гигантов вроде Amazon и VMware есть свои продукты для chaos engineering. Но для того, чтобы использовать внедрение сбоев вовсе необязательно использовать какое-то коробочное решение, на мой взгляд это ещё и неудобно. Проще использовать небольшие проекты, которые внедряют сбои какого-то одного класса и при необходимости добавлять их в тестирование. Я нарисовал такую схему, из которой понятно что можно использовать для внедрения сбоев и на каком уровне ОС оно работает. Нужно проверить обработку ошибок при работе с ФС - берешь одно, нужно проверить работу с сетью - берёшь другое. Открыть/Комментировать

2021-04-29 15:56:48 В 2020 году в почтовом сервере OpenSMTPD нашли уязвимость (CVE-2020-7247), которая позволяла злоумышленнику выполнить код на удалённом сервере с правами суперпользователя. Это наверное самый опасный класс уязвимостей в сфере безопасности ПО. Интересно тут вот что. Код OpenSMTPD написан одним из разработчиков OpenBSD, это одновременно безопасная, открытая и свободная реализация UNIX, компоненты которой разрабатываются с использованием различных способов для снижения вероятности успешной атаки на эти компоненты. OpenSMTPD в том числе разрабатывали с использованием этих подходов. Как же тогда появилась уязвимость с Remote Code Execution? Уязвимость была найдена в функции smtp_mailaddr(), которая имела некоторые ограничения на длину и набор символов, которые нужно экранировать («$», «|»). Исследователи Qualys смогли преодолеть эти ограничения, используя технику червя Морриса (одного из первых компьютерных червей, распространяемых через Интернет и первого, привлекшего значительное внимание СМИ), выполнив тело письма как сценарий оболочки в Sendmail. Напомню, что червь Морриса появился в 1988 году, то есть спустя 32 года эта техника эксплуатации уязвимости всё ещё работает.

(Добавлено) Подробное описание уязвимости - https://www.qualys.com/2020/01/28/cve-2020-7247/lpe-rce-opensmtpd.txt Открыть/Комментировать

2021-04-25 19:03:54 Если запустить фаззинг парсера JPEG, в качестве корпуса использовать картинку с зайцем, сохранять картинку с каждой мутацией и потом их все объединить в один GIF, то получится вот такая визуализация. Мне кажется это очень наглядное объяснение фаззинга. Открыть/Комментировать

2021-04-21 10:54:24 Считается, что дочь английского поэта и лорда Джорджа Байрона Ада Лавлейс была первым программистом. В 1842 – 1843 годах, Ада занималась переводом с французского лекции Бэббиджа об аналитической машине. К переводу прилагались заметки Лавлейс, причем они были в 3 раза больше статьи. Один из комментариев Ады подробно описывал алгоритм, по которому на аналитической машине можно было вычислить числа Бернулли. В дальнейшем эту работу признали первой программой, возможной к воспроизведению на компьютере, несмотря на то, что машина Бэббиджа так и не была сконструирована при жизни Ады. На приаттаченной картинке изображена диаграмма для вычисления числа Бернулли. И в это диаграмме есть баг, который заключается в том, что перепутаны местами делимое и делитель (v5/v4 -> v4/v5). Если это не опечатка, которую сделали в типографии, то это самый старый баг в истории вычислительной техники. Нагуглить рукописные заметки Ады , чтобы это проверить, сходу не получилось.

via Открыть/Комментировать

2021-04-20 10:49:33 Самые необычные тесты, с которыми я встречался, были в проекте KVM. Это тот проект, который реализует поддержку аппаратной виртуализации в Linux. За счёт него QEMU и другие виртуальные машины превращаются из медленной черепашки в виртуальную машину с достойной проиводительностью и пригодной для реального использования. Так вот в проекте KVM есть тесты, которые проверяют аппаратную часть внутри виртуальной машины сразу после её старта. Это тоже самое как тестировать на компьютере, на котором не то что приложений никаких нет, там нет операционной системы, которая выделит память и обеспечит другими ресурсами. Каждый такой тест сам по себе небольшая операционная система, которая самостоятельно выполняет инициализацию оборудования и даже имеет реализацию небольшого набора функций libc. После того, как виртуальная машина стартовала и внутри неё BIOS закончил инициализацию оборудования он передает управление одному из таких тестов. И что делает тест? Правильно, он включает MMU, инициализирует UART, это так называемая фикстура перед выполнением самого теста. А потом начинается тестирование, которое заключается в проверке перезагрузки контроллера клавиатуры, проверка контроллера прерываний, проверка эмуляции некоторых инструкций для CPU, проверка того, как CPU обрабатывает исключения, запуск и инициализация других CPU, если используется SMP. В некоторых тестах используются не только позитивные, но и негативные сценарии, а вот рандомизированного тестирования пока нет (хотя мне кажется было бы забавно иметь библиотеку для PBT, написанную на ассемблере). После завершения тестирования что делает тест? Конечно же сообщает результат. Так как он запущен один-одинёшенек, то способов сообщить что-то внешней программе в хостовой ОС не так много - нужно записать результат в специальное устройство, а тестовая инфраструктура прочитает это снаружи. И тест пишет 1 или 0 и скрипт, который запустил виртуальную машину с тестом, интерпретирует это как PASS или FAIL. Потом код теста выполняет выключение, виртуальная машина завершает выполнение и запуск этого теста на этом заканчивается.

https://www.linux-kvm.org/page/KVM-unit-tests Открыть/Комментировать

2021-04-12 15:21:09 Webdriver для Яндекс.Браузера

У Яндекса есть свой форк Chromium - Яндекс.Браузер. Почему-то для этого браузера нужен отдельный WebDriver, который называется Yandex.Driver. Так вот бинарные сборки этого драйвера яндексоиды публикуют на Гитхабе и исходного кода в репозитории нет. Может есть в подписчиках яндексоиды, которые могут пояснить за закрытый драйвер и странную схему распространения блоба через платформу для работы с открытым исходным кодом?

P.S. Если что, то исходный код chromedriver открыт под свободной лицензией (BSD).

https://github.com/yandex/YandexDriver Открыть/Комментировать

2021-04-10 12:42:28 Авиакомпания из Англии отдала разработку софта для регистрации пассажиров на рейс на аутсорсинг. В стране аутсорсинга слово “miss” использовалось для девочек и в результате все незамужние женщины получали вес в 35 кг при подсчёте веса самолёта. Как потерять контроль над языком и кодом одновременно.

https://www.theregister.com/2021/04/08/tui_software_mistake/ Открыть/Комментировать

2021-04-10 12:33:43 Для скриптов на Питоне появилась экспериментальная библиотека CrossHair, которая без выполнения программы ищет возможные пути выполнения и контрпримеры с помощью SMT-решателя (сейчас это популярный Z3). Для указания желаемого поведения программы можно использовать три способа: стандартные ассерты, PEP 316 и с помощью декораторов icontract. Авторы подчеркивают экспериментальный статус модуля: "Be aware that the absence of a counterexample does not guarantee that the property holds.". До появления CrossHair уже были похожие реализации (PEF: Python Error Finder, PyExZ3), но CrossHair является более полной реализацией идеи за счет поддержки символьных списков, словарей и коллекций. Есть интеграция с популярными IDE. Если интересны детали реализации, то они есть в документации и в публикации.

Зачем вообще это нужно? Разные инструменты находят разные баги. Если есть возможность раньше ("shift-left") и дешевле находить проблемы в коде, то почему бы этого не делать? В документации авторы ещё и проиллюстрировали аргументы. Открыть/Комментировать

2021-03-31 11:28:21 В одном из постов писал про Kernel CI - системе тестирования для ядра Linux. Вокруг неё сейчас много активности, проект спонсируют Collabora, Google, RedHat, Microsoft и другие компании. Но всё, что нужно сейчас знать про Kernel CI это то, что Линус Торвальдс выпускает ядра без учёта результатов тестирования в Kernel CI. Открыть/Комментировать

2021-03-24 11:58:21 Есть книга про параллельное программирование от инженера и исследователя Paul McKenney. В 2011 году он выложил её в открытый доступ под лицензией CC BY-SA 3.0 и продолжает дописывать её до сих пор (600+ стр.). Я про неё узнал из постов автора на LWN, где он рассказывал как верифицировать алгоритм RCU с помощью SPIN/Promela. Так вот в книге автор рассказывает о проблемах параллельного программирования начиная с того, как работает CPU и память (CPU pipeline, memory barriers, cache misses), потом переходит к поддержке мультипроцессорности в POSIX системах и далее к синхронизации и блокировках в проектировании систем.

Я бы не стал писать про это здесь, если бы автор не посвятил целых два раздела в книге валидации и формальной верификации параллельных систем. С первых строк хочется разобрать текст на цитаты:

"Where Do Bugs Come From? Bugs come from developers."

"When Should Validation Start? Validation should start exactly when the project starts."

"But never forget that the two best debugging tools are a thorough understanding of the requirements, a solid design and a good night’s sleep!"

Золотые слова!

Из интересного я бы выделил разделы про гейзенбаги и вероятности возникновения багов, изоляцию тестов друг от друга и выявление фактов влияния тестов друг на друга.

Ещё мне нравится что то, что пишет автор, основано на его собственном опыте. Тут нужно отметить, что Пол адвокат алгоритма RCU (read-copy-update) и этот алгоритм широко (в статье "RCU Usage In the Linux Kernel: One Decade Later" утверждается, что RCU используется в большинстве подсистем Linux ядра) используется в Linux ядре (как я понимаю это отчасти его заслуга, но не нашёл этому прямых подтверждений). И так как он занимался RCU и использованию RCU в ядре в частности, то и в книге многие примеры касаются RCU. Например про вероятности возникновения багов: "a million-year race-condition bug is happening three times a day across the installed base". Чтобы такие редкие баги найти уже не достаточно стандартных средств вроде инспекции кода, статического анализа и тестирования, нужны более изощрённые подходы. Поэтому часть багов в RCU нашли с помощью моделирования в SPIN, проверки кода с CBMC и с помощью мутационного тестирования.

Книга: https://mirrors.edge.kernel.org/pub/linux/kernel/people/paulmck/perfbook/perfbook.html Открыть/Комментировать