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

From

Gennady Mayko ()

To

Ihor Osov'yak ()

Date

2003-04-22T09:29:08Z

Area

SU.WINDOWS.NT.PROG

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

Добрый день!

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

 IOy> В дополнение...

 >> Да, и привидите пожалуйста пример, когда " ситуации, когда это не будет
 >> выполняться.", тем более что "легко представить "

 IOy> Я пока придумал только такую ситуацию, кода один процесс открывает
 IOy> устройство, потом хендл этого устройства передает дочернному процессу, а
 IOy> тот уже запускает  соотв. IOCTL... В таком случае драйвер получит
 IOy> некоректные данные при передачи данных к нему, а при возврате проста
 IOy> чего то пропишет по адресам первого процесса. Ибо указатели будут
 IOy> инициализироваться в дочеренем процессе, а чтение и запись реально будет
 IOy> осуществлятся в адресном пространстве первого процесса..
--
Чтобы это произошло, необходимо из первого процесса передавать не только
handle открытого драйвера, но и адрес передаваемых данных. Сложно себе
представить, зачем тогда это делать через второй процесс, потому что это уже
явно противоречит известным принципам меж-процессорного взаимодействия.

Если же второй процесс использует только handle драйвера и передает данные из
своего адресного пространства и драйвер является самым верхним в стеке
драйверов - то в принципе ничего страшного не произойдет (при условии,
конечно, что handle был передан корректно).


 IOy> Ну и если драйвер в таком случае не будет делать ProbeForWrite или
 IOy> ProbeForRead c cоотв. структурной обработкой исключений, то есть
 IOy> возможность завалить драйвер, а вместе сним и систему в случае
 IOy> вышеописаного финта в прикладных программах... Верны ли мои рассуждения?

 >> 
 >> --
 >> Отправлено через сервер Форумы@mail.ru - http://talk.mail.ru

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

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