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

From

Gennady Mayko ()

To

Ihor Osov'yak ()

Date

2003-04-22T09:18:52Z

Area

SU.WINDOWS.NT.PROG

From: "Gennady Mayko" <gennady.mayko@broadcom.com>

Добрый день!

 >> В принципе, если рассматриваемый драйвер всегда выполняется в адресном
 >> пространстве приложения, которое его вызывает, то это допустимо. Однако
 IOy> никто
 >> этого гарантировать не может и можно легко представить себе ситуации,
 IOy> когда
 >> это не будет выполняться.

 IOy> Спасибо за ответ.

 IOy> Если можно, то об этом несколько более подробно.. Я не совсем
 IOy> представляю
 IOy> себе механизм взаимодействия адресных пространсв драйвера и процесса.. В
 IOy> этом изделии драйвер запускается как сервис по запросу. Открывеется по
 IOy> имени устройства, созданного драйвером. По завершении работы приложения 
 IOy> драйвер
 IOy> не выгружается. Если приложение запустить снова, то все работет
 IOy> нормально.
 IOy> В каком процессе работает драйвер при первом запуске приложения и при
 IOy> втором? Как соотносятся адрессные пространства приложения и драйвера?
 IOy> Исходя из того, что наблюдаем, есть подозрение, что здесь происходит
 IOy> нечто подобное до мапирования длл на адрессное пространство процесса,
 IOy> использующего длл, только "наоборот". То есть адресное пространство
 IOy> процесса становится
 IOy> доступным для драйвера.. ??????????
--
Kernel mode адресное пространство является общим для всех работающих процессов
в Windows NT/2K/XP. Поэтому код kernel mode драйвера в принципе может
выполняться в контексте адресного пространства любого процесса. Код драйвера
сравнительно редко "знает", в рамках какого процесса (thread'a) он
выполняется, поэтому основывать проектные решения на том, что этот код всегда
будет выполняться в рамках конкретного процесса, скажем так,
непрофессионально.


 IOy> Да, и привидите пожалуйста пример, когда " ситуации, когда это не будет
 IOy> выполняться.", тем более что "легко представить "
--
При обработке сообщений IRP_MJ_DEVICE_CONTROL, соответствующая процедура
самого верхнего драйвера в стеке драйверов будет выполняться в контексте
процесса, в котором был вызов DeviceIoControl (это, наверное, и есть причина
того, что в рассматриваемом случае программа и драйвер работают). Но
достаточно установить upper-filter драйвер и это уже не гарантируется
(например, upper-filter драйвер может запустить системный thread и из него
посылать IRP "вниз" по стеку драйверов).


 >> Еще одной проблемой является то, что передача только указателя не
 IOy> позволяет в
 >> драйвере в общем случае определить размер передаваемых данных.
 >> 

 IOy> Ну там эта проблема решается до безобразия просто. Указатели - PChar,
 IOy> смотрят на буфферы выделенные с гарантированным запасом.. Данные -
 IOy> обычная нуль-терминейт строка...
--
Достаточно забыть об этом нуле и есть шанс полностью "обрушить" систему.
С другой стороны, если передавать такую же "плохую" строку явно в буфере,
размер которого задается при вызове функции DeviceIoControl, то или система не
сможет выделить место для такой строки и сразу же вернет ошибку, или это ей
удастся, строка явно сопируется в буфер и код драйвера будет безопасно с ней
работать.

--
С уважением,
Геннадий Майко.

--- ifmail v.2.15dev5
 * Origin: FidoNet Online - http://www.fido-online.com (2:5020/400)