В приложении создаю шаровую память для передачи информации с приложения в драйвер:

#define VIDEO_DRV_SIZE 2048 * 1536 * 3 +  3 * sizeof(int)   // прошу не ругать , поставил этого крокодила временно
......
        //create a memory share
        m_hMemoryShareDrv = CreateFileMapping(INVALID_HANDLE_VALUE,
            NULL,
             PAGE_READWRITE,
             0,
             VIDEO_DRV_SIZE,
             L"Global\\Restricted\\SplitCamDrvData");
        if (!m_hMemoryShareDrv)
        {
            return;
        }
        m_pBufMemoryShareDrv = (uint8_t*)MapViewOfFile(m_hMemoryShareDrv,   
                        FILE_MAP_ALL_ACCESS, 
                        0,                   
                        0,                   
                        VIDEO_DRV_SIZE);
...............

далее записываю в эту память инфу

    if (m_pBufMemoryShareDrv)
    {
        uint8_t* pBuf;
        uint32_t bufSz = win32::Bmp24GetBufferSize(iWidth, iHeight);
        memset(m_pBufMemoryShareDrv, 0, VIDEO_DRV_SIZE);
        memcpy(m_pBufMemoryShareDrv, &bufSz, sizeof(uint32_t));
        int i = sizeof(uint32_t);
        memcpy(m_pBufMemoryShareDrv + i, &iWidth, sizeof(uint32_t));
        i += sizeof(uint32_t);
        memcpy(m_pBufMemoryShareDrv + i, &iHeight, sizeof(uint32_t));
        i += sizeof(uint32_t);

    }

Все ок!
Теперь в драйвере подключаюсь к этой памяти

        RtlInitUnicodeString(&usSectionName, L"\\BaseNamedObjects\\Restricted\\SplitCamDrvData");
        InitializeObjectAttributes(&objAttributes, &usSectionName, OBJ_CASE_INSENSITIVE, NULL, NULL);

        status=ZwOpenSection(&m_SectionHandle,   GENERIC_READ, &objAttributes);
    
        if (NT_SUCCESS(status))
        {
            status = ZwMapViewOfSection(m_SectionHandle, ZwCurrentProcess(), 
                &m_pAddrMap, 0, viewSize, NULL, &viewSize, ViewShare, 0,
                PAGE_READONLY);
            if (NT_SUCCESS(status))
            {
......................................
            }
            else
            {
..............................................................
                ZwClose(m_SectionHandle);
                m_SectionHandle = NULL;
            }
        }

нет проблем, все мапируется.
Теперь в драйвере пробую почитать данный с приложения, используя m_pAddrMap

        int sz = 0;
        //memcpy(&sz, m_pAddrMap, 4);
        int * pData=(int*)(m_pAddrMap);
        sz=pData[0];

На последней строке Вин7 32 крешится. Что сделал не так?

А>На последней строке Вин7 32 крешится. Что сделал не так?

В контексте какого процесса зовётся ZwMapViewOfSection() и в каком контексте потом происходит обращение к памяти? Если, например, проецируешь в контексте вызывающего процесса, а читать потом пытаешься в потоке ядра, — получишь падение, естественно.

x64>В контексте какого процесса зовётся ZwMapViewOfSection() и в каком контексте потом происходит обращение к памяти? Если, например, проецируешь в контексте вызывающего процесса, а читать потом пытаешься в потоке ядра, — получишь падение, естественно.

В драйвере есть функция, которая вызывается периодически, когда надо прочитать кадр. При первом ее вызове я вызываю

 status = ZwMapViewOfSection(m_SectionHandle, ZwCurrentProcess(),

при последующих ее вызовах я обращаюсь к памяти.

Теперь в драйвере пробую почитать данный с приложения, используя m_pAddrMap

m_pAddrMap — usermode адрес и валидный только в контексте процеса, где была вызвана ZwMapViewOfSection, если обратиться по этому адресу в контексте другого процесса естественно KMODE_EXCEPTION_NOT_HANDLED(STATUS_ACCESS_VIOLATION)

Здравствуйте, Vicul, Вы писали:

V>В драйвере есть функция, которая вызывается периодически, когда надо прочитать кадр.
V>...

Рекомендую внимательно прочесть следующие статьи:
http://msdn.microsoft.com/en-us/library/windows/hardware/hh439648(v=vs.85).aspx
http://msdn.microsoft.com/en-us/library/windows/hardware/ff563705(v=vs.85).aspx

V>В драйвере есть функция, которая вызывается...

Короче, слушай внимательно. Про контексты и адресные пространства тебе уже объяснили. Далее, если тебе реально необходим доступ к проекции в любом контексте, то для решения проблемы варианта у тебя два: 1. [попроще] создать проекцию через ZwMapViewOfSection(), а при каждом обращении к памяти аттачиться к а.п. исходного процесса через KeStackAttachProcess(), однако доступ к такой памяти можно будет выполнять только на IRQL <= APC_LEVEL, или 2. [посложнее] сразу спроецировать память процесса в верхние адреса, которые "всегда доступны" в ядре, т.к. общие для всех процессов, это делается вызовами MmAllocateMdl(), MmProbeAndLockPages() и MmGetSystemAddressForMdlSafe(), — плюс в том, что память будет зафиксирована в физической памяти и к ней можно будет обращаться в прямом смысле отовсюду, включая повышенный IRQL, однако минус в том, что придётся тем или иным способом следить за уничтожением процесса, чтобы вовремя разблокировать страницы и удалить проекцию, иначе получишь сюрпризы типа такого.

вместо ZwMapViewOfSection — ObReferenceObjectByHandle + MmMapViewInSystemSpace

O>MmMapViewInSystemSpace

Да, но зачем же недокументированное предлагать при наличии правильной альтернативы (MmGetSystemAddressForMdlSafe)?

x64>Да, но зачем же недокументированное предлагать при наличии правильной альтернативы (MmGetSystemAddressForMdlSafe)?
Ну хотя бы потому, что юзермодный код может подкозлить пока там драйвер чухается — а именно отмапить адреса которые драйвер получил от ZwMapViewOfSection и подсунуть что-нить свое. А с точки зрения драйвера весь юзермод населен козлами. Исключая юзермод, имеющий включенную Administrators группу в токене — он тоже населен козлами, но этим можно доверять.

O>...весь юзермод населен козлами.

Иногда твоё образное мышление доставляет =)))

Всем спасибо за инфу, буду разбираться, потом отпишу, что получилось

x64>Короче, слушай внимательно. Про контексты и адресные пространства тебе уже объяснили. Далее, если тебе реально необходим доступ к проекции в любом контексте, то для решения проблемы варианта у тебя два: 1. [попроще] создать проекцию через ZwMapViewOfSection(), а при каждом обращении к памяти аттачиться к а.п. исходного процесса через KeStackAttachProcess(), однако доступ к такой памяти можно будет выполнять только на IRQL <= APC_LEVEL, или 2. о[/url].

что-то не выходит, взял первый вариант.

1. В конструкторе главного процесса запускаю поток

status = PsCreateSystemThread(
        &hThread,
        THREAD_ALL_ACCESS,
        NULL, NULL, NULL,
        Thread_proc, NULL);

2. в Thread_proc() подключаюсь к памяти приложения

#define VIDEO_DRV_SIZE 2048 * 1536 * 3 +  3 * sizeof(int)  
//глобальные
HANDLE g_SectionHandle;
PVOID g_pAddrMap;
BOOL g_bFlagExit;
PEPROCESS g_pMainProcess;

VOID Thread_proc(PVOID count)
{
......
    UNICODE_STRING usSectionName;
    OBJECT_ATTRIBUTES objAttributes;
    SIZE_T viewSize= VIDEO_DRV_SIZE;
    LARGE_INTEGER size;

    g_pMainProcess = IoGetCurrentProcess(); //для KeStackAttachProcess() !!!!!!!!!!!!!!

//инициализирую map

    size.HighPart = 0;
    size.LowPart = viewSize;
    
    RtlInitUnicodeString(&usSectionName, L"\\BaseNamedObjects\\Restricted\\SplitCamDrvData");
    InitializeObjectAttributes(&objAttributes, &usSectionName, OBJ_CASE_INSENSITIVE, NULL, NULL);

        status=ZwOpenSection(&g_SectionHandle,   GENERIC_READ, &objAttributes);
        ZwMapViewOfSection(g_SectionHandle, ZwCurrentProcess(), 
                &g_pAddrMap, 0, viewSize, NULL, &viewSize, ViewShare, 0, PAGE_READONLY);

        while (g_bFlagExit) { 
//длинный цикл пока деструктор главного процесса   не установит  g_bFlagExit = FALSE
           Sleep(1000);  //1 sec 
         }

        ZwUnmapViewOfSection(ZwCurrentProcess(), g_pAddrMap);
        ZwClose(g_SectionHandle); // функция

}

Все проходит на ура

3. Теперь когда драйвер вызывает ф-цию для чтения инфы , пытаюсь читать память

    if (g_pAddrMap && g_pMainProcess)
    {
        DbgPrintEx(DPFLTR_IHVVIDEO_ID,  DPFLTR_ERROR_LEVEL,    "CImageSynthesizer::SynthesizeBars - we have map\n");
        int sz = 0;
        if ( KeGetCurrentIrql() <= 2)
        {
            KAPC_STATE apcState;
            KeStackAttachProcess(g_pMainProcess, &apcState);
            memcpy(&sz, g_pAddrMap, 4);
            KeUnstackDetachProcess(&apcState);
            DbgPrintEx(DPFLTR_IHVVIDEO_ID,  DPFLTR_ERROR_LEVEL,    "CImageSynthesizer::SynthesizeBars - we have map: size: %i\n", sz);
        }
    }

на memcpy(&sz, g_pAddrMap, 4) — я снова получаю синий экран, что не так?

V>что-то не выходит, взял первый вариант.

Ну так анализ-то дампа по !analyze -v давай уже.

V> status=ZwOpenSection(&g_SectionHandle, GENERIC_READ, &objAttributes);

Лучше SECTION_MAP_READ, а не GENERIC_READ.
Вообще, старайся избегать указания generic-доступа.

V> ZwMapViewOfSection(g_SectionHandle, ZwCurrentProcess(),
V> &g_pAddrMap, 0, viewSize, NULL, &viewSize, ViewShare, 0, PAGE_READONLY);

Результат-то проверять надо!
А то вдруг g_pAddrMap равна NULL или мусор вообще.

V> while (g_bFlagExit) {
V> Sleep(1000); //1 sec

Ужастик, конечно.

V> if ( KeGetCurrentIrql() <= 2)

Во-первых, не 2, а DISPATCH_LEVEL.
Во-вторых, какой ещё DISPATCH_LEVEL?!
Максимум, APC_LEVEL здесь можно, я ж писал.

V> memcpy(&sz, g_pAddrMap, 4);

И не 4, а sizeof(int) лучше.

V>...снова получаю синий экран, что не так?

Анализ дампа давай, символы только настрой нормально.

x64>Ну так анализ-то дампа по !analyze -v давай уже.

Вот он

Microsoft (R) Windows Debugger Version 6.2.9200.20512 X86
Copyright (c) Microsoft Corporation. All rights reserved.

VOVA-ПК\vvova (npipe WinIDE_01CE41AA0B1A0953) connected at Thu Apr 25 14:43:04 2013

Microsoft (R) Windows Debugger Version 6.2.9200.20512 X86
Copyright (c) Microsoft Corporation. All rights reserved.


Loading Dump File [C:\Windows\MEMORY.DMP]
Kernel Summary Dump File: Only kernel address space is available

Symbol search path is: srv*
Executable search path is: 
Windows 7 Kernel Version 7600 MP (6 procs) Free x86 compatible
Product: WinNt, suite: TerminalServer SingleUserTS
Built by: 7600.17273.x86fre.win7_gdr.130318-1532
Machine Name:
Kernel base = 0x82c09000 PsLoadedModuleList = 0x82d51810
Debug session time: Thu Apr 25 14:07:09.225 2013 (UTC + 3:00)
System Uptime: 0 days 0:27:18.505
Loading Kernel Symbols
...............................................................
................................................................
....................................................
Loading User Symbols

Loading unloaded module list
............
*******************************************************************************
*                                                                             *
*                        Bugcheck Analysis                                    *
*                                                                             *
*******************************************************************************

Use !analyze -v to get detailed debugging information.

BugCheck 5, {859a2d08, 859a2d08, 1, 1}

Probably caused by : avshws.sys ( avshws+2ea1 )

Followup: MachineOwner
---------

eax=82d4017c ebx=82d3c202 ecx=0000000b edx=00000000 esi=82d32d20 edi=00000000
eip=82ce5b3c esp=82d2f938 ebp=82d2f950 iopl=0         nv up ei pl nz na pe nc
cs=0008  ss=0010  ds=0023  es=0023  fs=0030  gs=0000             efl=00000206
nt!KeBugCheckEx+0x1e:
82ce5b3c cc              int     3
0: kd> !analyze -v
*******************************************************************************
*                                                                             *
*                        Bugcheck Analysis                                    *
*                                                                             *
*******************************************************************************

INVALID_PROCESS_ATTACH_ATTEMPT (5)
Arguments:
Arg1: 859a2d08
Arg2: 859a2d08
Arg3: 00000001
Arg4: 00000001

Debugging Details:
------------------


DEFAULT_BUCKET_ID:  WIN7_DRIVER_FAULT

BUGCHECK_STR:  0x5

PROCESS_NAME:  System

CURRENT_IRQL:  2

LAST_CONTROL_TRANSFER:  from 82c9c7ba to 82ce5b3c

STACK_TEXT:  
82d2f950 82c9c7ba 00000005 859a2d08 859a2d08 nt!KeBugCheckEx+0x1e
82d2f97c c63daea1 859a2d08 82d2f9bc 4314d237 nt!KeStackAttachProcess+0x3f
WARNING: Stack unwind information not available. Following frames may be wrong.
82d2f9f0 c63d9e49 00000000 00000009 00000000 avshws+0x2ea1
82d2fb2c c63da44a 869fb640 82d2fb7c 82c7220d avshws+0x1e49
82d2fb38 82c7220d 869fb6f0 869fb640 078a886c avshws+0x244a
82d2fb7c 82c721b1 82d32d20 82d2fca8 00000001 nt!KiProcessTimerDpcTable+0x50
82d2fc68 82c7206e 82d32d20 82d2fca8 00000000 nt!KiProcessExpiredTimerList+0x101
82d2fcdc 82c703ee 00019a47 86c94288 82d3c280 nt!KiTimerExpiration+0x25c
82d2fd20 82c70218 00000000 0000000e 00000000 nt!KiRetireDpcList+0xcb
82d2fd24 00000000 0000000e 00000000 00000000 nt!KiIdleLoop+0x38


STACK_COMMAND:  kb

FOLLOWUP_IP: 
avshws+2ea1
c63daea1 a12cd83dc6      mov     eax,dword ptr [avshws+0x582c (c63dd82c)]

SYMBOL_STACK_INDEX:  2

SYMBOL_NAME:  avshws+2ea1

FOLLOWUP_NAME:  MachineOwner

MODULE_NAME: avshws

IMAGE_NAME:  avshws.sys

DEBUG_FLR_IMAGE_TIMESTAMP:  51790df8

FAILURE_BUCKET_ID:  0x5_avshws+2ea1

BUCKET_ID:  0x5_avshws+2ea1

Followup: MachineOwner
---------

V>> status=ZwOpenSection(&g_SectionHandle, GENERIC_READ, &objAttributes);

x64>Лучше SECTION_MAP_READ, а не GENERIC_READ.
x64>Вообще, старайся избегать указания generic-доступа.

попробую


V>> ZwMapViewOfSection(g_SectionHandle, ZwCurrentProcess(),
V>> &g_pAddrMap, 0, viewSize, NULL, &viewSize, ViewShare, 0, PAGE_READONLY);

x64>Результат-то проверять надо!
x64>А то вдруг g_pAddrMap равна NULL или мусор вообще.

я дал короткий вариант, вот полный код и если читать память в этой функции — все прекрасно работает

VOID Thread_proc(PVOID count)
{
    g_bFlagExit = TRUE;
    NTSTATUS status  = STATUS_SUCCESS;

    DbgPrintEx(DPFLTR_IHVVIDEO_ID,  DPFLTR_ERROR_LEVEL,    "Thread_proc started\n");

    UNICODE_STRING usSectionName;
    OBJECT_ATTRIBUTES objAttributes;
    SIZE_T viewSize= VIDEO_DRV_SIZE;
    LARGE_INTEGER size;

    g_pMainProcess = IoGetCurrentProcess();
    size.HighPart = 0;
    size.LowPart = viewSize;
    
    RtlInitUnicodeString(&usSectionName, L"\\BaseNamedObjects\\Restricted\\SplitCamDrvData");
    InitializeObjectAttributes(&objAttributes, &usSectionName, OBJ_CASE_INSENSITIVE, NULL, NULL);

    while(!g_SectionHandle && g_bFlagExit)
    {
        status=ZwOpenSection(&g_SectionHandle,   GENERIC_READ, &objAttributes);
        if (NT_SUCCESS(status))
        {
            DbgPrintEx(DPFLTR_IHVVIDEO_ID,  DPFLTR_ERROR_LEVEL,    "Thread_proc - ZwOpenSection STATUS_SUCCESS\\n");
            status = ZwMapViewOfSection(g_SectionHandle, ZwCurrentProcess(), 
                &g_pAddrMap, 0, viewSize, NULL, &viewSize, ViewShare, 0, PAGE_READONLY);
            if (NT_SUCCESS(status))
            {
                DbgPrintEx(DPFLTR_IHVVIDEO_ID,  DPFLTR_ERROR_LEVEL,    "Thread_proc - ZwMapViewOfSection is OK\n");
                break;
            }
            else
            {
                g_bFlagExit = FALSE;
                ZwClose(g_SectionHandle);
                g_SectionHandle = NULL;
                DbgPrintEx(DPFLTR_IHVVIDEO_ID,  DPFLTR_ERROR_LEVEL,    "Thread_proc - ZwMapViewOfSection is FAIL\n");
            }
            break;
        }
        DbgPrintEx(DPFLTR_IHVVIDEO_ID,  DPFLTR_ERROR_LEVEL,    " Thread_proc - ZwOpenSection error: %x\n", status);
        
        // wait for 1 sec
        Sleep(1000);
    }
    if (!g_bFlagExit)
    {
        g_bFlagExit = FALSE;
        DbgPrintEx(DPFLTR_IHVVIDEO_ID,  DPFLTR_ERROR_LEVEL,    "Thread_proc stoped\n");
        PsTerminateSystemThread(STATUS_SUCCESS);
        return;
    }
    
    ////read map
    while(g_bFlagExit)
    {
//!!!!!!!ВОТ КОД, КОТОРЫЙ я перенес, он здесь работает!!!!!!!!!!!!!!!!!!!!!!!!!! 
        int sz = 0;
        int iWidth = 0;
        int iHeight = 0;
        memcpy(&sz, g_pAddrMap, 4);
        if (sz)    
        {
            int i = 4;
            memcpy(&iWidth, (void*)((int)g_pAddrMap + i), 4);
            i += 4;
            memcpy(&iHeight, (void*)((int)g_pAddrMap + i), 4);
            i += 4;
            DbgPrintEx(DPFLTR_IHVVIDEO_ID,  DPFLTR_ERROR_LEVEL,    "Thread_proc - map: size: %i Width: %i Height %i\n", 
                sz, iWidth, iHeight);
        }
        Sleep(5);
    }

    if (g_pAddrMap)
    {
        ZwUnmapViewOfSection(ZwCurrentProcess(), g_pAddrMap);
        g_pAddrMap = NULL;
    }
    if (g_SectionHandle)
    {
        ZwClose(g_SectionHandle);
        g_SectionHandle = NULL;
    }
        
    g_bFlagExit = FALSE;
    DbgPrintEx(DPFLTR_IHVVIDEO_ID,  DPFLTR_ERROR_LEVEL,    "Thread_proc stoped\n");
    PsTerminateSystemThread(STATUS_SUCCESS);
}

V>> while (g_bFlagExit) {
V>> Sleep(1000); //1 sec

x64>Ужастик, конечно.

согласен, но Sleep вот

VOID FASTCALL Sleep(ULONG ulMilSecs)
{
   KEVENT         kEvent;
   LARGE_INTEGER   qTimeout;

   qTimeout.QuadPart = 10000L;
   qTimeout.QuadPart *= ulMilSecs;
   qTimeout.QuadPart = -(qTimeout.QuadPart);

   KeInitializeEvent(&kEvent,SynchronizationEvent,FALSE);

   KeWaitForSingleObject((PVOID)&kEvent,Executive,KernelMode,FALSE,&qTimeout);
}

V>> if ( KeGetCurrentIrql() <= 2)
x64>Во-первых, не 2, а DISPATCH_LEVEL.
x64>Во-вторых, какой ещё DISPATCH_LEVEL?!
x64>Максимум, APC_LEVEL здесь можно, я ж писал.

я смотрел по логу, функция вызывается с Irql == 2 (DISPATCH),
т.е в APC_LEVEL вообще я попасть не могу?

x64>Во-первых, не 2, а DISPATCH_LEVEL.
x64>Во-вторых, какой ещё DISPATCH_LEVEL?!
x64>Максимум, APC_LEVEL здесь можно, я ж писал.


Поставил вот так

    if (g_pAddrMap && g_pMainProcess && g_bFlagExit)
    {
        DbgPrintEx(DPFLTR_IHVVIDEO_ID,  DPFLTR_ERROR_LEVEL,    "CImageSynthesizer::SynthesizeBars - we have map\n");
        int sz = 0;
        if ( KeGetCurrentIrql() <= APC_LEVEL)
        {
            __try
            {
                KAPC_STATE apcState;
                KeStackAttachProcess(g_pMainProcess, &apcState);
                memcpy(&sz, g_pAddrMap, 4);
                KeUnstackDetachProcess(&apcState);
                DbgPrintEx(DPFLTR_IHVVIDEO_ID,  DPFLTR_ERROR_LEVEL,    "CImageSynthesizer::SynthesizeBars - we have map: size: %i\n", sz);
            }
            __except(EXCEPTION_EXECUTE_HANDLER)
            {
                g_bFlagExit = false;
                DbgPrintEx(DPFLTR_IHVVIDEO_ID,  DPFLTR_ERROR_LEVEL,    "CImageSynthesizer::SynthesizeBars - EXCEPTION\n");
            }
        }
    }

теперь при APC_LEVEL в эту ветку вообще не попадаю.

V>теперь при APC_LEVEL в эту ветку вообще не попадаю.

Разумеется, ты ж из таймера это делаешь (функция KiProcessTimerDpcTable в стеке), они на DISPATCH_LEVEL выполняются. Итого тебе: читать про DPC/таймеры в документации и думать, как перепроектировать драйвер (если возможно), потому что если будешь делать по варианту 2

Автор: x64
Дата: 23.04.13

, то работать-то оно будет, но нужно будет ещё синхронизацию правильную навесить, т.е. нельзя будет завершить процесс, страницы которого проецируешь, пока выполняется DPC/таймер. Вкратце, в момент завершения процесса (как ловить — тут есть варианты) ждать, пока не закончится работа с памятью (можно сам таймер ждать, можно событие, ...) и затем только отпускать процесс в вечный путь. Зачем это нужно — процесс может быть убит в любой момент, ты не контролируешь это.

Спасибо буду долбить теорию дальше

O>>...весь юзермод населен козлами.
x64>Иногда твоё образное мышление доставляет =)))
Профессиональная деформация секурити разработчика. Добавлю что если уж юзать ZwMap* и аттачиться к процессу — то лучше это городить в системном процессе — KeStackAttachProcess( PsInitialSystemProcess().. ) и вперед...

O>Добавлю что если уж юзать ZwMap* и аттачиться к процессу — то лучше это городить в системном процессе — KeStackAttachProcess( PsInitialSystemProcess().. ) и вперед...

Так ему ж память с процессом шарить надобно.
Предлагаешь а.п. ядра проецировать в процесс, что ли?

O>>Добавлю что если уж юзать ZwMap* и аттачиться к процессу — то лучше это городить в системном процессе — KeStackAttachProcess( PsInitialSystemProcess().. ) и вперед...
x64>Так ему ж память с процессом шарить надобно.
Ну процесс у него создает секцию сам (CreateFileMapping'ом) и сам же отображает себе в АП, а драйаер открывает по имени ту же секцию и отображает в АП системного процесса во избежание несчастных случаев. Все шарится и в тоже время все безопасно как Contex Classic. Вообще секция — это конечно не самый лучший и уж точно не самый простой способ обмениваться данными с драйверами, но раз уж ТС хочет именно так.. Может у него есть какие нить свои скрытые мотивы.

x64>Предлагаешь а.п. ядра проецировать в процесс, что ли?
Ась?