Маппирование памяти из user space в system space - Программирование драйверов - Ответ 6843513

Убежденный · 13.11.2014, 01:46

Сообщение от MickeyBlueEyes

Можно при передаче указателя запомнить процесс при помощи PsGetCurrentProcess, и потом при работе с этим указателем просто делать KeAttachProcess(результат PsGetCurrentProcess)

Только в этом случае следует сначала зареференсить указатель на процесс (ObReferenceObject).
А то процессы - они такие, иногда дохнут, а на их месте вырастают другие...

Сообщение от sergestus

А всегда ли при вызове драйвера (DeviceIoControl) он будет находиться в контексте вызвавшего его процесса?

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

Сообщение от sergestus

Драйвер вводит поток данных из устройства. Хочется иметь прямой доступ к данным из приложения, чтобы не делать системных вызовов.

В таком случае лучше сделать объект-секцию и использовать ее.
Фактически это и есть разделяемая память, только завернутая в объектный API системы.
Поищите в Гугле документ под названием "User-Mode Interactions: Guidelines for
Kernel-Mode Drivers", там такие вещи хорошо объясняются.

Сообщение от sergestus

Кажется это то, что мне нужно, насколько я понимаю буфер лочится в памяти при помощи MmProbeAndLockPages с параметром UserMode для буфера выделенного приложением ?

Да.
Не забудьте про try/except (и ProbeForRead/Write, если работаете с "сырым"
буфером, который пришел из user mode), иначе любой желающий с помощью
вашего драйвера сможет легко ронять систему в BSOD (без админских прав и т.п.),
или еще чего похуже. Про capture arguments и double fetch пока не пишу,
чтобы не пугать раньше времени

Сообщение от MickeyBlueEyes

Если память в свопе и будем на этих уровнях, то будет бсод

Не будет. Потому что:

MmProbeAndLockPages routine
http://msdn.microsoft.com/en-u... 85%29.aspx

MmProbeAndLockPages performs the following operations:

1. If the specified memory range is paged to a backing store (disk,
network, and so on), MmProbeAndLockPages makes it resident.

2. The routine then confirms that the pages permit the operation specified
by the Operation parameter.

3. If the memory range permits the specified operation, the routine locks
the pages in memory so that they cannot be paged out. Use the MmUnlockPages
routine to unlock the pages.

4. Finally, the routine updates the page frame number (PFN) array in
the MDL to describe the locked physical pages.

То есть, функция сделает блок памяти резидентным и заблокирует в памяти.
До вызова MmUnlockPages своппинг ему не грозит, можете писать туда
хоть на IRQL == HIGH_LEVEL

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

Из контекста нужного процесса.

C

int size = 128;
char* system_ptr = (char*)ExAllocatePool(NonPagedPool, size);
PMDL mdl = IoAllocateMdl(system_ptr, size, 0, 0, 0);
MmBuildMdlForNonPagedPool(mdl);
char* user_ptr = (char*)MmMapLockedPagesSpecifyCache(mdl, UserMode, MmCached, 0, 0, NormalPagePriority);

Тут не хватает try/except вокруг MmMapLockedPagesSpecifyCache, и по-хорошему,
системный буфер перед тем, как мапить в user mode, следует обнулить.
Мало ли там какие данные лежали до этого - пароли, имена, явки...

Вернуться к обсуждению:
Маппирование памяти из user space в system space Программирование драйверов