Entries:
Comments:
Posts:

Loading User Information from Channel 9

Something went wrong getting user information from Channel 9

Latest Achievement:

Loading User Information from MSDN

Something went wrong getting user information from MSDN

Visual Studio Achievements

Latest Achievement:

Loading Visual Studio Achievements

Something went wrong getting the Visual Studio Achievements

jayrava

jayrava jayrava

Niner since 2008

  • Juggs Ravalia – Windows CE 6.0 Device Driver Model

     

    Hello Sync --
    Sorry for the delay in writting. It's been long since CE 6 was released but let me see if I can recall those good old days.
    So, if the kernel driver services the user request on the caller's thread then it is a Synchronus call, otherwise it is an Asynchronous call. That's the simple way of finding out whether a call is Synchronus or not. An example of an Asynchronous call would be a client request on a user thread and then the driver servicing this user request on some other thread. Essentially the OS guarantees that the caller's process is mapped when the caller's thread is running and hence the kernel driver can be sure that it is accessing the correct buffer when doing so on the caller's thread.
    Consequently, you have to marshal buffers if you are going to service user requests asynchronously.
    Now let me answer the embedded pointer question. 
    Kernel drivers in CE 6.0 are fully trusted and have full access to kernel memory and kernel data structures. A malicious application can therefore pass an embedded pointer requesting the kernel driver to potentially modify kernel memory on its behalf. (It is analogous to the malicious application requesting the gun bearer - kernel driver in this case - to shot at a particular location). Kernel drivers therefore HAVE TO have to access check embedded pointers to prevent priviledge-attacks. The OS access checks first level pointers but has no knowledge of what the memory blobs contains and so it is the receipient's responsibility - the Kernel Driver's responsibility - to access check embedded pointers before using them. E
    In CE 5.0, MapCallerPtr was used. In CE 6.0, you have to use CeOpenCallerBuffer and CeCloseCallerBuffer to access check pointers. Example:
    struct MyStruct { UCHAR *pEmbedded; DWORD dwSize; };
    Windows CE 5.0 and prior versions
    // In XXX_IOControl...
    MyStuct *p = ( MyStruct*) pInput;
    g_pMappedEmbedded = MapCallerPtr(p->pEmbedded);
    // Fail if g_pMappedEmbedded == NULL ...
    Windows CE 6.0
    // In XXX_IOControl...
    hr = CeOpenCallerBuffer( (PVOID*) &g_pMappedEmbedded, pInput->pEmbedded, pInput->dwSize, ARG_I_PTR, FALSE);
    // Fail if FAILED(hr) == true
    // When done with pointer...
    hr = CeCloseCallerBuffer( (PVOID) g_pMappedEmbedded, pInput->pEmbedded, pInput->dwSize, ARG_I_PTR );
    The last parameter to the CeOpenCallerBuffer API is the fForceDuplicate flag - which when set to TRUE, requests the kernel to make a copy of the input buffers for security purposes.
    Let me know if you need further information on the Buffer Marshalling for Asynchronous access.

    Hello Sync --

     

    Sorry for the delay in writting. It's been long since CE 6 was released but let me see if I can recall those good old days.

     

     

    So, if the kernel driver services the user request on the caller's thread then it is a Synchronus call, otherwise it is an Asynchronous call. That's the simple way of finding out whether a call is Synchronus or not. An example of an Asynchronous call would be a client request on a user thread and then the driver servicing this user request on some other thread. Essentially the OS guarantees that the caller's process is mapped when the caller's thread is running and hence the kernel driver can be sure that it is accessing the correct buffer when doing so on the caller's thread.

     

    Consequently, you have to marshal buffers if you are going to service user requests asynchronously.

     

    Now let me answer the embedded pointer question. 

     

    Kernel drivers in CE 6.0 are fully trusted and have full access to kernel memory and kernel data structures. A malicious application can therefore pass an embedded pointer requesting the kernel driver to potentially modify kernel memory on its behalf. (It is analogous to the malicious application requesting the gun bearer - kernel driver in this case - to shot at a particular location). Kernel drivers therefore HAVE TO have to access check embedded pointers to prevent priviledge-attacks. The OS access checks first level pointers but has no knowledge of what the memory blobs contains and so it is the receipient's responsibility - the Kernel Driver's responsibility - to access check embedded pointers before using them. E

     

    In CE 5.0, MapCallerPtr was used. In CE 6.0, you have to use CeOpenCallerBuffer and CeCloseCallerBuffer to access check pointers. Example:

     

    struct MyStruct { UCHAR *pEmbedded; DWORD dwSize; };

     

    Windows CE 5.0 and prior versions

    // In XXX_IOControl...

     

    MyStuct *p = ( MyStruct*) pInput;

    g_pMappedEmbedded = MapCallerPtr(p->pEmbedded);

    // Fail if g_pMappedEmbedded == NULL ...

     

     

    Windows CE 6.0

    // In XXX_IOControl...

     

    hr = CeOpenCallerBuffer( (PVOID*) &g_pMappedEmbedded, pInput->pEmbedded, pInput->dwSize, ARG_I_PTR, FALSE);

    // Fail if FAILED(hr) == true

     

    // When done with pointer...

    hr = CeCloseCallerBuffer( (PVOID) g_pMappedEmbedded, pInput->pEmbedded, pInput->dwSize, ARG_I_PTR );

     

     

    The last parameter to the CeOpenCallerBuffer API is the fForceDuplicate flag - which when set to TRUE, requests the kernel to make a copy of the input buffers for security purposes.

     

    Let me know if you need further information on the Buffer Marshalling for Asynchronous access.

    Juggs--
    Sorry for the delay - but I moved on to other technologies and hence did not monitor this thread actively.

     

  • Juggs Ravalia – Windows CE 6.0 Device Driver Model

    Greetings Jason --

    Secure Copy largely entails making a copy of the caller's buffer to prevent asynchronous modifications of pointer values and the associated buffer size. Such data integrity issues can be solved by secure copying the input buffers via the CeAllocDuplicateBuffer API. Upon completion you have to free the memory by calling CeFreeDuplicateBuffer API.

    In your case, you want to access an embedded pointer asynchronously, so you will be calling CeOpenCallerBuffer and CeAllocAsynchronousBuffer as you mention above. In such scenarios - you are better off simply calling CeOpenCallerBuffer with the ForceDuplicate boolean parameter set to TRUE. This ForceDuplicate value will ensure that the call first makes a secure copy of the buffer and then access checks the copied buffer. The same parameter must be set when calling the corresponding CeCloseCallerBuffer API to free the secure copied buffer. This way the driver only works on a locally copied and access checked buffer - all async modifications will not affect the local copy.
  • Juggs Ravalia – Windows CE 6.0 Device Driver Model

    Greetings Victory --

    If you set the right BIB flags and Registry Keys for the DEVFLAGS, you will load your driver in user mode or kernel mode accordingly. To verify I would either put a break point in my driver code and see the callstack - the user mode driver is loaded in udevice.exe and usually on udevice.exe thread. the shell tools are being modified to help you on this one - gi mod used to enumerate modules will be upgraded to tell you modules loaded within a process - that way you know which dlls are loaded in kernel process versus udevice.exe
  • Juggs Ravalia – Windows CE 6.0 Device Driver Model

    I would look at the great presentation by Travis Horbla on Channel 9 on Porting BSPs -
    http://channel9.msdn.com/Showpost.aspx?postid=376154

  • Juggs Ravalia – Windows CE 6.0 Device Driver Model

    Hello Nitin,
    There are Windows CE 6.0 docs on porting BSPs from CE 5 to CE 6. There is a great presentation by Travis Horbla on Channel 9
    describing that too - http://channel9.msdn.com/Showpost.aspx?postid=376154
  • Juggs Ravalia – Windows CE 6.0 Device Driver Model

    Thanks Raja - We surely have a great, hardworking team.