Эффективное общение драйвера с юзермодом

Всем здравствуйте!

Товарищи, сам я в драйверах новичок и только начал заниматься, оттого хочу посоветоваться со знающими.
Пишу простой контент-фильтр, перехват решил производить через NDIS IM.

Вопрос:
На вход в драйвер льется трафик, судьбу содержимого каждого пакета решает юзермодное приложение.
Как лучше организовать их (драйвера и приложения) сотрудничество?
Стоит ли делать ожидание в драйвере или следует отдать пакет приложению, не передавая его дальше по цепочке, а завершить его, но приложение само при необходимости "даст ему ход"?
Чувствутю, второй вариант гораздо лучше.
Может какие еще есть варианты, более корректные?


Заранее очень благодарен!

 

Как лучше - это уже вопрос религии. Вам сейчас, возможно, приведут в пример множество вариантов, и большинство из них будут правильными. Также все зависит от конкретной постановки задачи. Если вы еще не читали книжку У. Они "Windows Driver Model"(лично мне она не очень - наверно надо было читать оригинал, а не перевод) - почитайте, возможно, что многие вопросы отпадут сами собой.

ЗЫ: ну и собств. мое, единственно верное ) мнение: если задача должна решаться в реальном времени, то на тот момент, когда ваш фильтр "увидит" пакет - он уже должен знать признаки, по которым необходимо предпринять какие-то шаги, и собств. - предпринять эти шаги ) . Т.о. следует предположить, что ваш юзермод должен лишь выполнять конфигурацию работы фильтра и, скажем с исп. именован. объекта синхронизации, должен быть оповещен о каких-либо аспектах работы фильтра и/или параметрах фильтруемых данных.

 

Т.е. вы имеете ввиду перенос всей логики фильтрования на сторону драйвера.
Нет, это не подходит. Причин много, некоторые из них:
- контент-фильтр - сам по себе достаточно сложный модуль, имеющий кучу алгоритмов определения "неугодных" данных и анлиза трафика, баз данных (например фильтр жаргонных слов) и т.п.;
- предполагается периодическое внесение изменений в основной код фильтрования.
Потому речь идет о создании драйвера - поставщика трафика. Разбор же трафика должен проводиться в юзермоде.

Так что рад был "услышать" те самые "множество вариантов"

 

Вариантов можно предложить уйму, как уже верно заметили.
Вот несколько, первое, что пришло на ум:
- передача пакета в LPC-порт и ожидание ответа с решением, юзермодное приложение является сервером.
- передача пакета в Pipe и ожилание ответа с решением, юзермодное приложение является сервером.
- доставка APC потоку юзермодного приложения (поток в юзермоде вечно делает for(; SleepEx(INFINITE,TRUE), приложение должно заранее передать в драйвер поток, в который нужно доставлять APC, и адрес APC Routine режима пользователя. пакет передается в структуре, адрес структуры - в параметре APC. решение записывается в ту же структуру. драйвер ждет на определенном Event'е, который сигналит APC Routine при завершени.
- создание нового потока в юзермодном приложении, пакет передается в структуре, адрес структуры - в параметре потока, решение записывается в ту же структуру. драйвер ждет на объекте потока.
...

Я бы честно выбрал вариант с LPC. Он прямо предназначен для обмена сообщениями.

 

Недокументировано.

Хороший вариант, так обычно и делаю.

Слишком большой оверхед, imho.

Недокументировано и, насколько я помню, имеет ограничение на размер сообщения.

 

Недокументировано, да. Но лучше всего подходит.
Есть вариант LPC с шаред мемори, если размер больше допустимого размера обычного сообщения.

Разве пайпы недокументированы? По-моему, в них можно писать из ядра обычным ZwWriteFile. А в юзермоде создание сервера документировано в мсдн.

 

Вопрос - бред. Юзермодное приложение при анализе пакетов от драйвера использует WinAPI?

 

LPC очень медленно. В сторону драйвера(кпл 3->0) перейти просто(шлюзы различные), вот назад уже сложнее, потомучно поток ядерный и не может нормально в юзермод перейти(например стека нет пользовательского, да и на ядерный нужно возвращаться). APC нормальное решение(для пользовательского потока быстродействие очень смутное понятие), лучше конечно шадова механизм калбэков использовать(или подобную реализацию), только недостаток заключается в вероятности сбоя, например поток может не вернуться в ядро(если например вызов в контексте произвольного потока). Стоит перенести весь критический по времени функционал в ядро.

 

Совсем уж недокументировано)

Зависит от того, насколько часто будут приходить пакеты. Это может быть и совершенно некритично.

 

Great
Если есть в сурцах венды значит документировано.

 

А я думал под документацией считается официальная документация. Все остальное может быть изменено в последующих версиях без уведомления

 

Ах да, можно еще сделать механизм аналогичный тому, как win32k получает нажатия от клавиатуры и мыши.
Создать девайс, юзермодное приложение в цикле читает из него, а драйвер завершает IRP только при возникновении события.

JustAGuest
Достаточно тебе вариантов?

 

Да, с этой точки зрения да, просто в ядре пайпы это как чёрный ящик, тупо читать/писать можно и всё. К слову, пайпы по производительности почти одинаково с Ioctl-ами обычными будут.

 

Это утверждение может быть корректно только там, где иначе никак.

 

Спасибо, товарищи! Думаю остановиться на варианте с APC.

 

Great
Хотя с твоим вариантов АРС, возникает такой вопрос: как драйвер поведет себя в случае если вердикт по пакету еще не получен, но пришел уже следующий пакет? Возможно ли тут рентабельность?

 

Ну APC ставятся в очередь. И исполняться будут в порядке помещения в очередь. Все пакеты будут обработаны юзермодным рабочим потоком в порядке их получения

 

а не слишком ли сложно для анализа траффика в реальном времени?

 

поподробнее можно про второй вариант? мне кажется, что он во-первых не корректен, а во-вторых придется завершать вообще ВСЕ пакеты, а потом большинство из них отправлять заново. где тут выигрыш в скорости? смысл в этом есть только если часть логики фильтра перенести в драйвер и передавать в юзермодное приложение только подозрительные пакеты.

вопрос к тем, кто уже имеет опыт в написании таких фильтров: это вообще корректно завершать пакеты, а потом их заново отправлять, или тут есть подводные камни?

 

Насчёт NDIS IM конкретно не скажу, но у тебя должна же быть какая-то очередь? В обычных I/O-based фильтрах каждому потоку в каждый момент времени соответствует один запрос, и таким образом, проблемы не возникает. Т.е. пришёл запрос в фильтр, положили его в очередь, создали событие для этого запроса и ждём результатов, здесь же, в этом же потоке. Но в NDIS IM такого нет и быть не может, не тот уровень уже. Ну у тебя пакеты же куда-то приходят, какой-то колбек вызывается при этом? Вот в этом колбеке кладёшь пакет в очередь, сигналишь приложение через APC и возвращаешь управление. Ждать результатов от приложения в этом колбеке нельзя, ибо тогда есть вероятность, что на больших скоростях часть пакетов будет теряться при переполнении внутренних буферов tcp/ip стека и поэтому здесь ты должен предусмотреть такой размер очереди, который компенсирует временные издержки на взаимодействие с приложением. Ну а приложение по сигналу начинает выгребать пакеты и для каждого пакета сигналить драйверу, что с ним делать. Как-то так.

Какая ещё рентабельность? Может быть реентерабельность всё таки, не?