Подскажите пожалуйста, возможно ли из драйвера вызвать пользовательскую функцию? Точнее есть драйвер, есть программа мною написанные, теперь хотелось бы, чтобы драйвер оповещал программу о наступлении какого-либо события и быть может передавал параметры. Понятно, что это возможно реализовать через постоянные запросы. А без этого никак? Если никак, то с каким интервалом посоветуете производить обращения к драйверу? Спасибо.
не будьте тимом робертсом (этот только умеет вместо ответа, сказать что во первых это ни хрена не нужно, во вторых не будет работать, в третьих те кто это уже делали дураки и сделали не так как нужно Т.Р. это такой парень который в osr очень болтать и всех посылать любит. По моему глубокому убеждению драйвера это тот же самый код как и юсермод. Отличие что не напишите на php ну и при ошибках просто нужен reboot, все другое это просто детали. Главное не боятся. Насчет событий... они есть точно так же как и в usermode. Например: в юсермод делаем CreateEvent через DeviceIoControl отправляем handle события в драйвер в юсермоде начинаем ждать события через WaitForSingleObject в нужном потоке в драйвере в IRP device control ловим IO_REFERENCE_EVENT и через ObReferenceObjectByHandle получаем это событие если оно сработало то из драйвера вызываем KeSetEvent если оно драйверу не нужно вызываем ObDereferenceObject. Возможно где то я ошибся но в принципе должно работать примерно так. Удачи!
Если IRQL = PASSIVE_LEVEL заюзать Iretd, указав юзермодные селекторы и предварительно определённый гделибо указатель на стек(например в TEB) и организовать возможность обратного вызова, впрочем как и работают все калбаки Ki*. Либо использовать какойлибо из системных механизмов, например APC, либо диспетчер исключений использовать(идея эта весьма хороша). Nerka По вашему код режима ядра ограничевается IRP и эвентами ?
Nerka В корне не согласен. В ядре надо делать только то, что нельзя сделать в user mode. То есть, самый минимум. Причины: стабильность системы, простота отладки, простота замены компонента и "дружественность" по отношению к другим прогам (то есть, гоняй себе процессы/потоки в user mode, хотя мог бы жрать проц в dispatch level) ov4inka по-нормальному, делается это через стандартный ReadFile() или DeviceIoControl(). Просто в ядре положи его в очередь и обработай тогда, когда понадобится. В user mode - либо blocking call, либо overlapped IO.
"хотелось бы, чтобы драйвер оповещал программу о наступлении какого-либо события и быть может передавал параметры. Понятно, что это возможно реализовать через постоянные запросы. А без этого никак?" вот такой бил начальный вопрос. Так что я вообще не понимаю причем тут какие то IRQL, селекторы, TEB, PEB и чужая прочь... "По вашему код режима ядра ограничевается IRP и эвентами ?" Нет, я так не думаю, но будучи в здравом смысле ответил на вопрос который человек спросил. (А не про какие то IRQL которые не имеют ни малейшего отношения к заданному вопросу). P.S. флейма не будет, я больше не намерен отвечать ни на какой вопрос в этой теме.
Nerka Вам бы с "x64" обьединится, вместибы нашли чем заняться, изучалибы пиар десятилетней давности http://x64.blog.ru/ Если не нужна гибкость, не нужна скорость, не нужно скрывать, всё документировано, пишем на паскале тогда да, с вами согласен. PS: От вас флейма нет, тока некропостенг
To s0larian: "В ядре надо делать только то, что нельзя сделать в user mode." Ты меня не понял. С етой фразой я согласен. А просто говорил про то что некоторые люди чувствуют какой то порог который опасно перешагнуть. А ведь на самом деле будь это код kernel mode или user mode он неотличатеся процессору. Это все тот же машинный код (о привилегиях говорить не будем, они инструкций не меняют). "то есть, гоняй себе процессы/потоки в user mode, хотя мог бы жрать проц в dispatch level" Ну а вот тут ты уже неправ. Скорость кода ничем не отличается user от kernel. Даже если засесть на RTC то процессор не будет ничего гонять быстрее. Это просто иллюзия от того что scheduler чаще выполняет один thread нежели другой. Моя мысль была в том что не надо пугать людей с драйверами. Конечно их нужно пользовать тогда когда нужно. Но когда нужно, то не надо бояться. А то я вижу тенденции от тех кто что либо в этом понимают, запугивать новичков (скорее всего просто потому что показаться "я в этом деле мастер, а ты просто даже не лезь это слишком сложно, трудно и т.д.", в конечном счете новички после нескольких bugcheck и бросают затею). Да я понимаю что опасно обезьянам гранаты раздавать, но ми все ими когда то были
Clerk "Если не нужна гибкость, не нужна скорость, не нужно скрывать, всё документировано, пишем на паскале тогда да, с вами согласен." ах вот ты обо чем. Ну если ты и намерен выиграть несколько циклов то уж будь добрым, неучи этому других (ведь не все вирусы пишут). Уж лучше как сказал s0larian ради стабильности дрова вообще не писать нежели такой дурдом как в место KeSetEvent всякую чушь применять. Наверное будь я проклят если ты еще кому нибудь не советовал usermode код запускать через APC (видя страсть в TEB залезать ).
Nerka Слушай, если не понимаешь про что речь идёт лучше промолчи. Какие несколько циклов, вали отсюда матчасть учи про смену колец защиты.)
Clerk не сердись, будь поспокойнее, дольше жить будешь А вот про то что поучится то я так скажу. Раз я уже выучил то я знаю правильный ответ на заданный вопрос (и так бы ответили 99.99% всех кто драйвера пишут). Ну а те что остались и пишут вирусы, канечно лезут в usermode напрямую. Не потому что они пышут какой нибудь супер код для embedded девайсов, а потому что квалификации нет еще. Ну ничего, когда то все повзростают
Nerka Мне нравится ядерный чистый код, подобный код ты можешь видеть у обработчиков прерываний, планировщика и пр., код который "работает с процессором", если так можно выразится, там нужны глубокие знания(рас речь пошла про это). Механизм доставки и обработки пакетов для меня не представляет никакого интереса, более того квалификации никакой там не нужно. Это высокоуровневые механизмы, и чтобы использовать их знать как устроено и работает ядро ниже, чем тот уровень, на котором создаётся обёртка драйвера(дрочево с MajorFunction etc) не нужно. Это ведь и сказано: Вот именно на этом уровне и разницы нет в том, юзермод это, либо режим ядра. И кодер не понимающий более глубоких принципов работы системы, который ниже пакетов никогда и не спускался, как ты - всеголишь шелуха. А как иначе - дай реализовать подобную задачу тому, кто знает как это реализовать в виде самодостаточного кода(без какоголибо функционала системы вообще), реализовать посредством IRP - для него это расплюнуть. А вот подобную задачу реализовать сишному высокоуровневому кодеру - вот он уже в тупике, ибо столкнулся с TEB, GDT и прочем впервые. Это факт как не крути. Более того, предложенное решение посредством IRP - это вызов функции в драйвере, а не вызов драйвером пользовательской функции. Ты предложил решение задаче, обратной поставленной. Хотя драйвер ответит и вернёт некоторые данные, но это не является вызовом пользовательской функции.
Clerk, вопрос содержал две части (см. ниже), и я начинаю думать что ми про разные вещи говорим. Ты про первую часть, я про вторую. 1) возможно ли из драйвера вызвать пользовательскую функцию? 2) хотелось бы, чтобы драйвер оповещал программу о наступлении какого-либо события
Если юзермодная функция простая и юзает только память то можно вызвать и так просто передать управление. Чтоб выполнялась в режиме ядра. Какая разница-то если это какая-нибудь ntdll.RtlInitUnicodeString Но если она сложная и с вызовами в ядро через sysenter тогда потребуется сделать переходник. Через события как нонейм предложил, но можно и проще. Если интересует, пиши - напишу. Щас впадлу и надо ноут спаивать, не рабоает. А то volodya опять будет ругаться.
