| Форумы
ЧАТ |
Орешник |
|
| Форумы -» | Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG |
|
| ||
|
|
Новости |
Поиск |
FAQ |
Статьи |
Книги |
Новости VCL
| | Форумы ЧАТ |
Орешник |
|
| |||
| |||
| |||
« предыдущая ветвь | форум | следующая ветвь »
DeviceIoControl,METHOD_BUFFERED ;и данные ;по поинтеру Win32, [NT4, Win2k, WinXP]
Ihor Osov'yak © (2003-04-21 20:15:00)идущие вглубь драйвера.
То есть, в драйвер передаются не сами данные, а поинтер на них.
Драйвер потом успешно эти данные получает. Примерно по такой же схеме данные возвращаются, только там не METHOD_BUFFERED, а METHOD_NEITHER.. Область данных, на которые смотрят эти поинтера распределяются конечео в win32 и на время выполнения DeviceIoControl живы и нкуда не исчезают - DeviceIoControl выполняется в синхронном режиме.
Я был убежден, что это чушь, пока сам не увидел работающего изделия по такому принцыпу и его исходники.. Которые сам компилил :-).
Это дело проверялось под W2K.
То есть получается, что из kernel mode можно работать по поинтеру, который передан из пользовательского режима?
Насколько така техника безопасна?
Зы - я в общеи то заинтересован доказать, что так работать плохо...
Зы2. А причем здесь делфи? Да притом, что win32 app на делфи нарисовано...
Ihor Osov'yak (2003-04-22 17:55:00) [1]Удалено модератором
Ihor Osov'yak (2003-04-22 17:39:00) [2]2 Digitman © (22.04.03 15:11)
Ну, ньюансов много..
Начиная от того, что обработка должна выполнятся в контексте того процесса, который сделал запрос.. И это условие ножет просто нарушитть некий драйвер-фильтр... Он вряд-ли сделает это, когда идет IOCTL с METHOD_NEITHER.. Но для METHOD_BUFFERED этот фильтр имеет полное право сделать такой финт, в смысле сменить контекст процесса, в котором будет идти обработка запроса, наивно полагая, что все нужные данные находятся в системном буфере копий (к примеру, запустить отложенную обработку процедуры). И тогда по нашему указателю мы ничего хорошего не получим..
Еще момент - область памяти, на которую смотрит указатель, может уйти в своп.. Как быть с такой ситуацией?...
Да, еще. Я не говорю, что я много чего видел на тему сабжа, но немного смотрел всякие решения. Там везде данные для обмена лежали в пределах штатных буфферов, а не торчали неизвестно где, а в буффере - только указатель... Это меня и насторожило...
Не могли бы Вы привести пример использования такой техники в источниках, заслуживающих на доверие, к примеру в самплах от DDK, или в том=же сисинтерналс, они некоторые вещи снабжают исходниками...
Спасибо за внимание..
Digitman (2003-04-22 15:11:00) [3]
> получается, что из kernel mode можно работать по поинтеру,
> который передан из пользовательского режима?
а почему бы и нет ? что в этом механизме есть нонсенс ?
> Насколько така техника безопасна?
Настолько же, imho, насколько безопасен сам по себе синхронный (блокирующий) механизм вызовов/исполнения ф-ций ядра
Кто же ещё (2003-04-22 13:03:00) [4]Удалено модератором
Ihor Osov'yak (2003-04-22 12:19:00) [5]Удалено модератором
Ihor Osov'yak (2003-04-22 11:43:00) [6]2 Кто же ещё (21.04.03 22:35)
Спасибо за внимание, но Вы не очень внимательно читали описание ситуации. Дело в том, что поинтер указывает на данные, лежащие за пределами пользовательского буфера обмена. Собственно в самом буфере - только значение поинтера.. То есть, совершенно не важно, перейдет это значение напрямую или через промежуточный буффер.
.. Зы. Как я представляю себе, эта ситуация более-менее работоздатна, если запрос будет выполнятся в контексте процесса вызывающего приложения. Если нет - то будет кырдык. В смысле, по поинтерах мы ничего не получим. Когда это может произойти? Да к примеру кто-то навесил фильтрирующий драйвер, который обработку соотв. запроса передаст нам не сразу, а через механизм отложенного вызова процедур... Или другой пример - более извратный - другой поток в пользовательском приложении уничтожает буфер, на который смотрят наши указатели.. Конечно, здесь имеет место явная ошибка в пользовательском приложенни, но это говорит о наличии того обстоятельства, что драйвер может стать жертвой ошибки в win32, что очень не хорошо...
Да, еще - пример для фильтрируещего драйвера с отложенным вызовом процедур и METHOD_NEITHER ввиду приведенных выше рассуждений о контексте процесса наверно также есть потенциально опасным? C METHOD_NEITHER я в своих изделиях не работал..
Спасибо за внимние..
Кто же ещё (2003-04-21 22:35:00) [7]Для METHOD_BUFFERED выделяется промежуточный буфер, для METHOD_NEITHER нет.
Здесь фишка в скорости, и только. Там, где гоняют большие объёмы данных, используют METHOD_NEITHER.
Разумеется, второй метод потенциально опасней :)
| |
