Re: DeviceIoControl,METHOD_BUFFERED и данные по поинтеру Win32,

From

Ihor Osov'yak ()

To

Eugene Muzychenko ()

Date

2003-04-22T12:19:06Z

Area

SU.WINDOWS.NT.PROG

From: "Ihor Osov'yak" <osi@osi.te.ua>


Первым делом спасибо за ответ.

"Eugene Muzychenko" wrote in message

> Привет!
>
> 21 Apr 03 20:17, you wrote to All:
>
>  Iy> То есть, в драйвер передаются не сами данные, а поинтер на них.
>
> Ну а как ты представляешь себе передачу в драйвер "самих данных"
> неопределенного заранее размера? ;)

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

 Относительно "неопределенного заранее размера". Передается поинтер на zero
terminated str, PChar то бишь.. Я конечно понимаю, что драйвер в таком
случае станет жертвой ошибки win32  приложения, если оно этот zero
terminated в передаваемую строку не положит. Как я понимаю, это есть первый
недостаток этого решения. При передачи даных от драйвера указатели смотрят
на буфера, которые имеют заведомо достаточный размер (в этом изделии драйвер
возвращает по указателю не более, чем 1024 байта). То есть здесь можно
придраться только к тому, что приложение передаст некоректный указатель, или
само же уничтожит приемный буфер в каком-то другом потоке.. Но это уже...
даже не знаю как сказать..




>
>  Iy> Драйвер потом успешно эти данные получает. Примерно по такой же схеме
>  Iy> данные возвращаются, только там не METHOD_BUFFERED, а
METHOD_NEITHER..
>  Iy> Область данных, на которые смотрят эти поинтера распределяются
>  Iy> конечно в win32 и на время выполнения DeviceIoControl живы и никуда
>  Iy> не исчезают - DeviceIoControl выполняется в синхронном режиме.
>
> При BUFFERED буфер _всегда_ виден - он выделяется в системном пуле,
который
> доступен в любом контексте.

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

>
>  Iy> То есть получается, что из kernel mode можно работать по поинтеру,
>  Iy> который передан из пользовательского режима? Насколько така техника
>  Iy> безопасна?
>
> Если указатель "родной" пользовательский (NEITHER, без переотображения) -
то
> можно его использовать лишь в уверенности, что тебя вызвали напрямую из
> user-mode. Соответственно, класть его куда-нибудь "на потом" недопустимо.


Сам драйвер, с которым я разборку затеял, никуда его потом  не откладывает.
Обрабатывает сразу. Но здесь есть опасность того, что в системе кто-то
навешает драйвер-фильтр, который соотв. запрос передаст нам не сразу, а
через механизм отложенного вызова процедур... Эту мысль подросил Gennady
Mayko, если я его правильно понял... Но как я понимаю, при NEITHER
драйвер-фильтр обязан передавать запросы вниз в контексте того процесса, в
котором он получил запрос.. То есть получается, что для случая  NEITHER эта
техника (драйверу передаем только значение указателя, а он уже по значению
указателя напрямую обращается к данным пользовательского приложения) будет
худо-бедно работать, если не брать во внимание потенциальных граблей,
которые можно расставить в пользовательском режиме.

Могут быть проблемы для BUFFERED, когда обработка будет продолжаться в
контексте  процесса, отличного от того, котор?й сформировал эти указатели на
данные в юзверь режиме. А это может слычиться при постановке
драйвера-фильтра, который будет использовать механизм отложенной обработки
запросов..


>
>  Iy> Зы - я в общем то заинтересован доказать, что так работать плохо...
>
> Как именно?

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

Еще раз спасибо за внимание.

Ihor Osov'yak.



-- 
Отправлено через сервер Форумы@mail.ru - http://talk.mail.ru
--- ifmail v.2.15dev5
 * Origin: Talk.Mail.Ru (2:5020/400)