Еще раз про взаимодействие User-Kernel mode

Здравствуйте!

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

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

P.S.: Забыл написать, что при такой операции нужно учитывать возникновение, в процессе ожидания драйвером ответа пользователя, еще одной фильтруемой ситуации, т.е. еще один процесс попытается получить доступ к сети и драйвер должен правильно понять пользователя, т.е., если пользователь разрешил второму, но не разрешил первому, то именно так драйвер и должен поступить, т.е. должна быть возможность какой-то маркировки ситуаций и передачи этого маркера от драйвера - программе и наоборот.

 

ksu_ant, через IOCTL:

User mode

1)

- hFile = CreateFile(символьный линк

- WriteFile(hFile,

2)

- hFile = CreateFile(символьный линк

- DeviceIoControl(hFile,

Kernel Mode

MajorFunction[IRP_MJ_DEVICE_CONTROL] = Example_IoControl;

ну... в инете масса примеров, к примеру посмотри исходники FileMon от Руссовича.

Код (Text):

1.      *    Input Buffer = Irp->AssociatedIrp.SystemBuffer
2.      *    Ouput Buffer = Irp->MdlAddress
3.      *
4.      *    Input Size   =  Parameters.DeviceIoControl.InputBufferLength
5.      *    Output Size  =  Parameters.DeviceIoControl.OutputBufferLength
6.  

 

LuckyDevil через IOCTL:

Это понятно.

Вопрос вот в чем: в драйвере функцией Dispatch... перехвачена фильтруемая ситуация, отправлен код уведомления в GUI, драйвер ждет ответа, но, при этом, он не должен останавливать мониторинг всех остальных процессов.

 

ksu_ant

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

 

Не знаете ли Вы, где об этом можно почитать, или исходники какие-нибудь найти.

 

ksu_ant Если это тот исходник, который был выложен, то для общения с UserMode там нехватает создания виртуального девайса и символьной ссылки на него

LuckyDevil Хорошая идея с отложенным IRP Можно сделать так:

UserMod

hFile = CreateFile(символьный линк...

ReadFile(hFile,....., Overlaped);

Это даст асинхронный ввод/вывод. Пришёл пакет - драйвер откладывает IRP и устанавливает Event. UserMode ловит Event и читает/записывает данные, в зависимости от решения юзверя IRP либо пропускается, либо нет.

Только в этом есть одна тонкость это только теоретические раскладки. Для деталей есть книжка Солдатова "Программирование драйверов...." Там про отложенные IRP написано.

 

SteelRat

Если это тот исходник, который был выложен, то для общения с UserMode там нехватает создания виртуального девайса и символьной ссылки на него

Допишем .

Спасибо за помощь, SteelRat.

А Солдатова почитаем. Но если есть еще чего-нибудь у кого-нибудь ()), не стесняйтесь, буду рад полезным предложениям.

 

Правильно я понимаю, что под фразой отложенные IRP, понимались Отложенные процедурные вызовы (DPC)?

 

Да

 

На конкретную реализацию механизма "опроса юзверя" можешь посмотреть в исходниках на www.hxdef.org/knowhow.php, может пригодиться.

 

Спасибо, посмотрю.

 

<font color="gray][ ksu_ant</font><!--color--><font color="gray]: Правильно я понимаю, что под фразой отложенные IRP, понимались Отложенные процедурные вызовы (DPC)? ]</font><!--color-->



Нет! DPC здесь вообще не при чём. Под "отложенным IRP" здесь следует понимать IRP, который пришёл драйверу, но он не хочет/может его завершать/форвардить в данный момент. Он помещает его в свою собственную очередь таких же отложенных IRP. Очередь - это просто двусвязный список или надстройка над ним, как например "Cancel-Safe IRP Queue". Когда приходит время драйвер достает IRP из очереди и дальше всё идет как обычно - завершает его или форвардит. См. в ДДК "Driver-Managed IRP Queues". Пример использования той же "Cancel-Safe IRP Queue" можно посмотреть в DDK\src\general\cancel, только отменять их тебе, скорее всего, не нужно будет.



Многие ДДК'ашные примеры используют самый простой вариант (например, DDK\src\input\kbdclass).



Поставить в очередь:

Код (Text):

1. KeAcquireSpinLock(&DeviceExtension->SpinLock, &irql);
2. IoMarkIrpPending (Irp);
3. InsertTailList (&DeviceExtension->Queue, &Irp->Tail.Overlay.ListEntry);
4. KeReleaseSpinLock (&DeviceExtension->SpinLock, irql);
5.  
6. return STATUS_PENDING;

Забрать из очереди:

Код (Text):

1. KeAcquireSpinLock(&DeviceExtension->SpinLock, &irql);
2. RemoveEntryList(&Irp->Tail.Overlay.ListEntry);
3. KeReleaseSpinLock(&DeviceExtension->SpinLock, irql);

+ пляски вокруг Cancel Routine, которые я для простоты опустил.



Как всё это будет работать применительно к сетевым запросам я не знаю.

 

Спасибо, а я уже сеть начал копать по DPC . Одна проблема, - примера Cancel у меня DDK нет.

Firewall взят мною для примера, т.е. мой драйвер с сетью работать не должен.

 

Сырец





_1080594642__cancel.rar

 

либа+хидер



_441821892__csq.rar

 

Возможно будут проблемы со сборкой из-за отсутствия wdmsec.h и либы. Замени IoCreateDeviceSecure на IoCreateDevice.



"Cancel-Safe IRP Queue" - это хороший пример надстройки над Irp->Tail.Overlay.ListEntry когда нужна отмена IRP. СтОит ли её использовать в твоём случае - хз.

 

Большое спасибо!

Все скачал, буду вечером дома изучать. Если это поможет мне решить мою проблему, - будет просто замечательно.

 

Доброе утро!

Работа вроде двигается. Так долго молчал потому что не было времени плотно сесть за компьютер.

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

Отсюда вопрос: как можно открыть устройство в такой ситуации?

Буду благодарен за все ответы.

 

Вопрос наивный, но ты не пробовал открывать девайс до того, как программа попробует это сделать ? В исходнике то стоит Exclusive=False...

 

Пока не пробовал (сегодня попробую). Я уже подумал об этом.

Но не возникнет ли в такой ситуации проблем у той программы, которая хочет открыть устройство монопольно?