Comments 40
> // Компилятор ругается, если мы не используем какие-либо параметры функции (мы не используем параметр Driver)
// Это наиболее корректный способ избежать этого предупреждения
UNREFERENCED_PARAMETER(Driver);
Выглядит очень костыльно.
NTSTATUS KmdfHelloWorldEvtDeviceAdd( In WDFDRIVER /*Driver*/, Inout PWDFDEVICE_INIT DeviceInit )
Простой коммементарий или отпил имении параметра выглядит логичней.
Но я ++овик, могу быть неправ, что это валидное решение для мира Си. Но так в среднем решают такую проблему в Google style guide.
Выглядит очень костыльно.
Но это общепринятый способ для всего WinAPI. К слову, в обычном Си также есть похожая идиома с приведением выражения к void. Чтобы такое выглядело чуть менее костыльно, подобные стопки следует писать уже после return, в самом хвосте кода функции.
Простой комментарий или отпил имени параметра выглядит логичней.
В стандартном переносимом Си (по крайней мере, до C99 включительно) такого делать нельзя.
https://stackoverflow.com/questions/8 776 810/parameter‑name‑omitted‑c-vs‑c
Зачем два компьютера? Виртуалки наше всё. Устанавливаете систему, делаете контрольную точку. Если отлаживаемая система легла, восстанавливается в течении минуты.
Если драйвер для реального устройства - то его не всегда возможно\удобно пробрасывать в виртуалку. Но для чисто программных драйверов я бы тоже выбрал виртуалку - да.
Да, согласен, совсем забыл об этом упомянуть. Сейчас добавлю в статью.
Если пишем драйвер, работающий с реальным железом, например с шиной PCI, как у автора, то виртуалка не поможет. В виртуалку можно прокинуть определенное устройство, но не шину целиком. Но и в случае с отдельным устройством - драйвер из виртуалки вполне может положить нам хостовую систему, в случае некорректной работы с DMA например.
Ух ты. А есть какие-то примеры и так далее?
Это-ж вектор атаки такой что мама не горюй. Ради интереса из под стандартного Windows Sandbox пытался сделать что-то с хостом. Не получилось. А уж из под Hyper-V даже пробовать не стал. Там вроде как полная изоляция...
Думаю, речь шла о пробросе заведомо сбойного PCI устройства в виртуалку, и уже непосредственно из виртуалки создание условия, когда устройство начинает "делать грязь", к примеру, через DMA. Вряд ли это можно назвать уязвимостью.
Китайские USB2COM адаптеры ложат vmware только в путь.
Да виртуалку то положить большого ума не надо. :) A вот из виртуалки положить хост... Это уже интересно.
попадались usb2com с кривыми драйверами, которые например при физическом выдёргивании шнурка без закрытия порта стабильно вызывали у виндов синий экран.
ну а положив каким-нибудь таким образом сначала виртуалку и проброс устройства можно затем и за хоста взяться :)
без относительно виртуалки у хоста же ведь тот же кривой драйвер для этого устройства.
Если хост — линукс, то вполне себе поможет. Там можно кусок шины застабить и прицепить к виртуалке. Но нужна поддержка в железе.
Если надо работать чисто с шиной PCI, как у автора, то поможет и виртуалка (там виртуальная шина PCI ничем не хуже, чем настоящая), и, например, qemu. Если надо отладить драйвер работы с простым устройством, то можно взять qemu и туда добавить стаб-версию этого устройства (что может быть полезно само по себе для вещей типа автотестов). Если надо работать с реальным железом, то конечно лучше отдельный подопытный комп, независимо от того, есть там DMA, проецируемая память, прерывания или нет.
Интересно ещё. Сам подобным давно уже не занимаюсь, но в своё время был класный пакет Numega driver studio назывался. Устанавлвался как плагин для VS6, ставил в систему драйвера свои и позволял прямо из VS, из режима пользователя драйвера отлаживать. Я прямо в виртуалке всё разворачивал и работал. Есть ли что то подобное сегодня?
Да и SoftICE был хорош, тоже интересно :)
NT ядро сейчас не терпит вмешательств (пресловутый PatchGuard), так что хорошим решением для более-менее быстрой отладки - это vmware/vbox + VirtualKD
Вместо KdPrintEx гораздо удобнее использовать TraceEvents из WPP Software Tracing (если создавать проект в Visual Studio, то он уже будет настроен в шаблоне проекта). Это позволит потом в TraceView фильтровать логи по топикам и уровням.
Вместо копирования структур и определений ioctl в юзерспейсную программу, надо использовать Public.h в проекте драйвера. Там еще и есть полезные макросы, которые позволят нормально работать с 64-битным драйвером из 32-битного приложения (это очень полезно для разного рода библиотек).
Так а под какую винду в итоге этот драйвер, под 10-ую?
А что, в 10-11 винде можно вот так просто запустить неподписанный драйвер? У меня в свое время проблема была загрузкой драйвера для программатор. Под семеркой он работал, а десятка посылала лесом, потому что драйвер был не подписан.
Неподписанный драйвер можно запустить если только специально загружаться с отключенной проверкой подписей
Необязательно, есть и другие способы загрузить свой драйвер, но драйвер должен быть к этому готов
Да, под 10-ую
Если следовать руководству Майкрософт по разработке первого драйвера, на которое я ссылаюсь в статье, то Visual Studio автоматически сконфигурирует целевой компьютер для запуска неподписанных драйверов.
Так же можно отключить проверку подписей вручную с помощью следующих команд:bcdedit.exe -set loadoptions DISABLE_INTEGRITY_CHECKS
bcdedit.exe -set TESTSIGNING ON
Здесь был комментарий, оставленный случайно))
Неужели нужно писать драйвер чтобы перечислить подключенные устройства?
Вроде даже в реестре это лежит? Или это другое?
ну, к слову говоря, драйвер можно было и не писать, а взять уже готовый подписанный валидный легитимный, типа AsrDrv101, гигабайтовский GIO, асусовский AsUpIO или вообще RwDrv... но да, так интереснее (:
Кривой драйвер потер файлы с сохранениями игр?
Кривой драйвер не давал запуститься Виндовс, так что пришлось возвращать её в исходное состояние(то есть в состочние на момент установки). При этом все файлы на системном диске были удалены, в том числе и часть сохранений.
сохранить нужные файлы перед возвращением в исходное состояние вы еще не проходили?
В тот момент принципиально важным было спасти свои лабы и курсовой, которые я и сохранил. Про игры как то не вспомнилось.
В любом случае мой пример с сейвами - это предупреждение о последствиях, к которым может привести отсутствие точки восстановления. Сохранить нужные файлы всегда можно, но зачем делать это самому, если это дело можно поручить системе ?
Загрузиться с livecd и удалить кривой драйвер (или подпихнуть ей заведомо работающий драйвер), потом загрузить винду, которая может чуть-чуть поругается - профит. Не зайдёт?
Также, по задаче, нужно определиться:
либо делаете некоторый драйвер в стиле Hello World (что Вы собственно и сделали) и это хорошо и полезно.
либо делаете работу с портами ввода-вывода. Пардонь-те, но ioctl это не порты ввода-вывода, от слова "совсем". Для общения через порты ввода/вывода лучше сделать физическое устройство, оно отобразит (например) регистры на адреса портов и тогда будете гонять данные взад/вперёд. Либо Вам задана задача пробежать все устройства и подёргать у них порты. В общем, туманно.
ЕС смогли продавить USB-C, осталось продавить сторонние магазины приложений и тогда вопрос с банковскими приложениями будет решен.
Интересная тема - помню, в качестве диплома писал небольшой драйвер для Win10 под KMDF. Совершенно взрывает мозг, нормальным программированием это назвать трудно. Вот некоторые интересные факты:
Как уже сказали, нужно два компа. Я обошелся VirtualBox'ом, но запуск и подключение дебаггера занимали минуты, поэтому в интернете нашел и установил "ускоритель дебага" - так и не понял, что это было, но работало, хотя с feedback loop обычной программы не сравнить.
Любая ошибка типа segfault - и на машине синий экран. Не очень удобно)
При хите брейкройнта зависает вообще все, не двигается даже мышь (что логично). При дебаге некоторых драйверов это экстремально неудобно.
Всю полезную инфу пришлось искать на бородатых хакерских форумах. На stackoverflow драйверная тема как-то непопулярна. Из чтения форумов сложилось впечатление, что многие хаки из 90х работают и в современном KMDF. Очень консервативная индустрия.
Дебаг из студии не работал, поэтому пользовался WinDbg. Такого дебаггера и врагу не пожелаешь, реально как будто вернулся на двадцать лет назад.
Вопреки расхожему мнению, драйверы для винды можно писать на C++. Но есть нюанс - запрещены исключения (то есть минус stdlib), динамическая аллокация памяти (минус new и malloc) и RTTI (уже не так критично), и вроде что-то ещё. В итоге основные классы типа векторов и строк пришлось реализовывать с нуля или брать специальные для kernel mode (таких либ в открытом доступе кот наплакал).
Дебаг из студии не работал, поэтому пользовался WinDbg. Такого дебаггера и врагу не пожелаешь, реально как будто вернулся на двадцать лет назад.
В Microsoft Store есть современная версия WinDbg Preview - возможности те же, но интерфейс намного удобнее.
драйверы для винды можно писать на C++.
Более того, KMDF сам по себе написан на C++. Но это скорее C с классами, чем C++.
(минус new и malloc)
Если сильно надо, можно реализовать свои operator new/delete с ExAllocatePool под капотом
Опять студенты не хотят учить команды DOS, ну ладно, пусть пишут под Windows XP
DOS, чёрной пеленой экран заполнил чистый DOS,
Мышь потеряла форму, стала вдруг квадратной мышь,
Я разбил «окно», 95-ое мастдайное «окно»,
И поставил DOS, и тогда я понял: это счастье — вот оно.
Актуальный гайд по написанию простого Windows-драйвера