Двусторонняя связь между драйвером режима ядра и пользовательским приложением?

Мне нужна двусторонняя связь между драйвером WFP в режиме ядра и приложением пользовательского режима. Драйвер инициирует связь, передавая URL-адрес приложению, которое затем классифицирует этот URL-адрес (Entertainment, News, Adult и т. Д.) И передает эту категорию обратно в драйвер. Драйвер должен знать категорию в функции фильтра, поскольку он может блокировать определенные веб-страницы на основе этой информации. У меня был поток в приложении, который делал запрос ввода-вывода, который будет содержать драйвер с URL-адресом и GUID, а затем приложение будет записывать категорию в реестр под этим GUID, где драйвер подберет его. К сожалению, как указал верификатор драйвера, это нестабильно, поскольку функции реестра Zw должны запускаться на PASSIVE_LEVEL. Я думал о том, чтобы попробовать то же самое с сопоставленными буферами памяти, но я не уверен, что для этого требуются требования прерывания. Кроме того, я думал о снижении уровня прерывания перед вызовом функции реестра, но я не знаю, каковы его побочные эффекты.

1
nl ja de
Вы уже используете обычный ввод-вывод от драйвера к приложению для передачи URL-адресов; почему бы не использовать обычный ввод-вывод, чтобы вернуть результат?
добавлено автор Harry Johnston, источник
Поскольку запрос инициируется драйвером, я не мог понять, как заставить его работать. Приложение делает запрос ввода-вывода, драйвер завершает его с URL-адресом в выходном буфере, а затем как приложение получает информацию обратно к драйверу, так как запрос ввода-вывода завершен? Кроме того, операция чувствительна к времени, потому что я принимаю решение о блокировке веб-страницы.
добавлено автор jeffm, источник

3 ответы

Вам просто нужно иметь два разных типа ввода-вывода.

Если вы используете DeviceIoControl , чтобы получить URL-адреса (я думаю, что это был бы самый подходящий метод), это так же просто, как добавление второго кода управления ввода-вывода.

If you're using ReadFile or equivalent, things would normally get a bit messier, but as it happens in this specific case you only have two kinds of operations, one of which is a read (driver->application) and the other of which is a write (application->driver). So you could just use WriteFile to send the reply, including of course the GUID so that the driver can match up your reply to the right query.

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

2
добавлено

PASSIVE_LEVEL ничего нестабильно. Доступ к реестру должен быть на PASSIVE_LEVEL, поэтому это невозможно сразу, если драйвер работает на более высоком IRQL. Однако вы можете сделать это, разгрузив рабочий элемент. Понижение IRQL обычно не рекомендуется, поскольку это противоречит намерениям ОС.

Your protocol indeed sounds somewhat cumbersome and doing a direct app-driver communication is probably preferable. You can find useful information about this here: http://msdn.microsoft.com/en-us/library/windows/hardware/ff554436(v=vs.85).aspx

1
добавлено
Извините, я мог бы сформулировать это лучше. Он «нестабилен» в том смысле, что он не падает каждый раз, но функции фильтра WFP работают на DISPATCH_LEVEL, поэтому функции реестра неуместны.
добавлено автор jeffm, источник

Поскольку выноски находятся в DISPATCH, ваша обработка должна выполняться либо в рабочем потоке, либо в DPC, что позволит вам использовать ZwXXX. Вы должны перевернутые обратные вызовы для целей связи, есть хороший документ в OSR.

Я только начал совать WFP, но он похож даже на образцы, которые они предоставляют, Microsoft повторно загружает пакеты. Я не заглянул в нее так близко, но кажется, что они отбрасывают пакет и повторно вводят всякий раз, когда обрабатываются. Этого будет достаточно для того, чтобы ваш механизм режима использования принял решение. Вы также должны ограничить захват пакетов определенным портом (80 в вашем случае), чтобы не выполнять дополнительную обработку, которая вам не нужна.

0
добавлено
Про Windows
Про Windows
941 участник(ов)

Microsoft Windows и всё, что с этим связано. Список интересных групп и каналов: https://github.com/goq/telegram-list

Microsoft Developer Community Chat
Microsoft Developer Community Chat
584 участник(ов)

Чат для разработчиков и системных администраторов Microsoft Developer Community. __________ Новостной канал: @msdevru __________ Баним за: оскорбления, мат, рекламу, флуд, флейм, спам, NSFW контент, а также большое количество оффтоп тем. @banofbot