Информация об изменениях

Сообщение Re[2]: Кто как пишет юнит-тесты для драйверов NT + Моя идея от 30.09.2018 19:29

Изменено 30.09.2018 22:27 LimyKurn

Re[2]: Кто как пишет юнит-тесты для драйверов NT + Моя идея
Здравствуйте, okman, Вы писали:

O>Здравствуйте, LimyKurn, Вы писали:


O>Я использую иной подход, который более в духе концепций юнит-тестирования: код калбэка переносится в

O>user mode (обычный проект C++ в Visual Studio), все недостающие функции ядра заменяются своими "прокси"
То есть можно считать, что ты уже начал писать такую систему, т.к. что-то там у тебя есть? Я тоже начал, под конкретный драйвер.
Первое, что я сделал, это реализовал ExAllocatePoolWithTag на malloc, ExFreePoolWithTag на free, и макрос для проверки на утечки. Планируется полноценная песочница для памяти и нормальное профилирование для поиска утечек.
Объединиться бы нам как-то, что ли.
Только вот сильно беспокоит финансовая часть проекта. Я, конечно, буду и сам иногда писать какие-то драйвера. Но вот работать у Касперского, Аваста, вообще в команде — желания нет. А вот если мою систему оценят разработчики Касперского, Аваста, или хоть чего помельче, то буду искренне рад принести им пользу и получить за это заслуженное вознаграждение. Даже если они просто напишут: "отличная идея, скорее делайте и заливайте на гитхаб, ждем с нетерпением", как мне ответили в одной американской фирме на предложение написать для них некую библиотеку, то это уже что-то.
Соответственно, следует как-то поговорить с такими ребятами — что они думают об идее песочницы.

Но и если песочницу отвергнут, то, в принципе, можно и так:
O>Представь, что нужно покрыть тестами код minifilter калбэка, который, скажем, блокирует изменение
O>атрибутов безопасности файла или папки. Чтобы проверить это "в бою", нужно запустить виртуальную машину,
O>перевести ее в тестовый режим, проинсталлировать туда свой драйвер, приаттачить его к нужному тому,
O>затем с помощью тестового приложения, которое, кстати, еще придется написать, вызвать соответствующую
O>функцию, обработать результат и каким-то образом сообщить "наверх" о том, пройден ли тест или провален.
O>Да, а еще предусмотреть зависание виртуалки или выпадание ее в BSOD... Жуть.
Если его один раз сделать, то дальше уже не такая жуть будет.

Ну и да, по ссылке выше от -prus- тоже надо посмотреть.

А вот если вообще никому эти тесты толком не нужны — тогда увы

Немного технической информации:
Если все-таки песочница, то я ее начал делать не используя Visual Studio, а используя лишь сам WinDDK. Но эта идея оказалась несостоятельной — очень не хватает уже можно догадаться чего — std::vector и std::string :D
Второй момент — не хватает плюшек по синтаксису вроде лямбд.
Так что VS в этом плане рулит. Хотя по-хорошему и сами драйвера надо в ней писать — а у нас вот проект в WinDDK 7.1, собирается батниками, а пишется в блокноте, никакой VS — оттуда и возникла порочная идея юзать такую же систему для тестов.

O>Другая фаза — функциональные и прочие тесты. Вот там уже приходится писать всякие тестовые

O>запускалки, проверяющие поведение в реальных условиях. Думаю, здесь логичнее использовать
O>вообще не C/C++, а что-то более легковесное, например python.
Я это вручную делаю пока.
Re[2]: Кто как пишет юнит-тесты для драйверов NT + Моя идея
Здравствуйте, okman, Вы писали:

O>Здравствуйте, LimyKurn, Вы писали:


O>Я использую иной подход, который более в духе концепций юнит-тестирования: код калбэка переносится в

O>user mode (обычный проект C++ в Visual Studio), все недостающие функции ядра заменяются своими "прокси"
То есть можно считать, что ты уже начал писать такую систему, т.к. что-то там у тебя есть? Я тоже начал, под конкретный драйвер.
Первое, что я сделал, это реализовал ExAllocatePoolWithTag на malloc, ExFreePoolWithTag на free, и макрос для проверки на утечки. Планируется полноценная песочница для памяти и нормальное профилирование для поиска утечек.
Объединиться бы нам как-то, что ли.
Только вот сильно беспокоит финансовая часть проекта. Я, конечно, буду и сам иногда писать какие-то драйвера. Но вот работать у Касперского, Аваста, вообще в команде — желания нет. А вот если мою систему оценят разработчики Касперского, Аваста, или хоть чего помельче, то буду искренне рад принести им пользу и получить за это заслуженное вознаграждение. Даже если они просто напишут: "отличная идея, скорее делайте и заливайте на гитхаб, ждем с нетерпением", как мне ответили в одной американской фирме на предложение написать для них некую библиотеку, то это уже что-то.
Соответственно, следует как-то поговорить с такими ребятами — что они думают об идее песочницы.

Но и если песочницу отвергнут, то, в принципе, можно и так:
O>Представь, что нужно покрыть тестами код minifilter калбэка, который, скажем, блокирует изменение
O>атрибутов безопасности файла или папки. Чтобы проверить это "в бою", нужно запустить виртуальную машину,
O>перевести ее в тестовый режим, проинсталлировать туда свой драйвер, приаттачить его к нужному тому,
O>затем с помощью тестового приложения, которое, кстати, еще придется написать, вызвать соответствующую
O>функцию, обработать результат и каким-то образом сообщить "наверх" о том, пройден ли тест или провален.
O>Да, а еще предусмотреть зависание виртуалки или выпадание ее в BSOD... Жуть.
Если его один раз сделать, то дальше уже не такая жуть будет.

Ну и да, по ссылке выше от -prus- тоже надо посмотреть.

А вот если вообще никому эти тесты толком не нужны — тогда увы

Немного технической информации:
Если все-таки песочница, то я ее начал делать не используя Visual Studio, а используя лишь сам WinDDK. Но эта идея оказалась несостоятельной — очень не хватает уже можно догадаться чего — std::vector и std::string :D
Второй момент — не хватает плюшек по синтаксису вроде лямбд.
Так что VS в этом плане рулит. Хотя по-хорошему и сами драйвера надо в ней писать — а у нас вот проект в WinDDK 7.1, собирается батниками, а пишется в блокноте, никакой VS — оттуда и возникла порочная идея юзать такую же систему для тестов.

O>Другая фаза — функциональные и прочие тесты. Вот там уже приходится писать всякие тестовые

O>запускалки, проверяющие поведение в реальных условиях. Думаю, здесь логичнее использовать
O>вообще не C/C++, а что-то более легковесное, например python.
Я это вручную делаю пока. Написана тестовая утилита на C#, но она не автоматическая — надо жать на кнопки в окошке. И результат она не анализирует — его надо смотреть самому.