Связь между режимами ядра и режима пользователя
Мне известно о связи в режиме ядра из пользовательского режима, и я также знаю о событиях / инвертированных вызовах, однако мне нужно отправить строковое значение в процесс пользовательского режима из драйвера устройства режима ядра, а затем ждать в KM для ответа (например, TRUE или FALSE BOOLEAN).
Возьмите строку «c: \ file.txt». Теперь мне нужно, чтобы драйвер устройства KM отправил эту строку в пользовательский режим, а затем чтобы эта программа единой системы обмена сообщениями повторно отправила ответ ИСТИНА или ЛОЖЬ для обработки драйвером.
Я просмотрел множество тем / постов на сайте, примеров документации и не могу найти то, что ищу.
Я думал, что, возможно, я мог бы установить поток в программе пользовательского режима, который просто непрерывно ждет, пока данные не поступят, а затем в KM я как-то делаю паузу, пока ответ не возвращается обратно … не уверен
Любая помощь приветствуется.
Решение
Вам, вероятно, нужно три IOCTL.
- IOCTL_READ_FROM_KERNEL. Изначально отправляется после подключения и ждет первого сообщения ядра
- IOCTL_RESPOND_AND_READ_FROM_KERNEL. Отправляет ответ и ждет следующего сообщения.
- IOCTL_RESPOND. Отправляет ответ.
Код режима пользователя вызывает IOCTL. IOCTL_RESPOND немедленно возвращается, и поток, вероятно, завершается.
Остальные 2 IOCTL будут ждать, пока ядру что-нибудь отправить. Это будет включать в себя некоторую форму идентификатора, которая может быть использована для идентификации сообщения.
Когда у ядра есть сообщение, оно может искать ожидающие потоки единой системы обмена сообщениями или помещать сообщение в очередь для последующей доставки.
Когда единая система обмена сообщениями подключается, она снимает очередь доставки или добавляется в очередь официантов.
Другие решения
У вас есть множество вариантов.
- Порты
- Именованные трубы
- В ожидании IOCTL
- Внедрение кода
- Shared Events -> теперь читает файл конфигурации из пользовательского режима
Первая упомянутая методика официально поддерживается для драйверов устройств мини-фильтра файловой системы, и № 3 и № 5 относительно просты. Принимая во внимание, что № 2 и № 4 являются более сложными и менее надежными / подходящими 9 раз из 10.
Тем не менее, вы можете реализовать Named Pipes из режима ядра с некоторой недокументированной магией; адрес для NtCreateNamedPipeFile может быть извлечен из KeServiceDescriptorTable. NtCreateNamedPipeFile будет полагаться на IoCreateFile — IoCreateFile — это экспортированная подпрограмма режима ядра, к которой вы можете свободно обращаться. Все остальное просто реализовать для именованного конвейерного сервера в режиме ядра, и, если вы только после реализации клиента, это еще проще, потому что все, что вам нужно будет использовать, — это простые процедуры Native API, такие как ZwCreateFile, ZwWriteFile, ZwReadFile, и т.п.
Я рекомендую вам обратиться к Портам для общения, у Microsoft есть несколько собственных примеров для этого на GitHub.