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

Juggs Ravalia – Windows CE 6.0 Device Driver Model

Download

Right click “Save as…”

The upcoming release of Windows CE 6.0 ships with a redesigned kernel, memory model and device driver architecture, Juggs Ravalia is a Program Manager on the Windows CE drivers team who gives us the low down on the new driver architecture and what that means for embedded device developers. Mike Hall, Senior Product Manager and Channel 9 correpsondent, conducts this interview.

Tags:

Follow the Discussion

  • LiQLiQ
    There was a lot of knowledge shared here. I can't say I understood it all, but it's really inspirational.

    I think this clip was better than the other on CE 6.0. Seems like a lot of confusion in that clip.

    Great job. Show us your... skills... Wink
  • Thanks LiQ for your comments

    Let me know what needs further clarification if any and I will do my best to explain it better Wink
  • Will watch the video tonight.  Question:
    I asked a question to Peter Wieland on his Channel 9 video of UMDF about if the source code for a UMDF can be recompiled in the Windows CE 6.0 environment and the Driver will run.   He replied and left the question open.

    You can of course see the benifits of this just as WDM did for Windows 98 and Windows 2000.   You get of course "free" drivers shared between Windows and Windows CE.

    -William Michael Jones



  • I enjoyed the video.
    (1) On all of the interviews on Channel 9, why not use the PC tablet instead of a white board.  Hard to see the white board.  Cool app time maybe for creating presentations.  Use it here then sell it.
    (2) Just a suggestion, synchronous and asynchronous sounded exactly the same Juggs on the Video.
    (3) After adjusting to the two above the presentation was Excellent.  You are clear and you convey understanding. Thank you. I for one liked when you showed how some of the supported Kernal apis are supported in both kernel and user mode.  Also the statement the Reflexor is the nucleus of the UMDF. 
    (4) Using UMDF in Windows CE stills teases me with respect to porting code from Windows to Windows CE.
  • Hi Juggs,

    How many drivers do my Windows Embedded CE Device has on an average ?
  • William

    We have been working hand in hand with Peter Wieland to make sure our technologies align well. That said, drivers today on the desktop and CE are of different forms and whenever we think of introducing WDM compatibility for CE, we always wonder if there are a ton of chips shared across the two platforms and the ROM Size implications

    Rest assured, we are always working to get the best for our customers for all platforms
  • Mjones--

    1) Cool idea, the white board is quite clear in reality. The camera capture might need to tweaked.

    2) Right the notion of synchronous and asynchronous here might be confusing, but of highly important value and so I will clarify here:

    When porting your drivers to CE 6, if the driver is going to access the caller's buffer on the caller's thread, then it falls under the synchronous access arena and you dont have to do any marshalling since the kernel driver can access the caller's buffer directly. That is to say that the kernel 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.

    If on the other hand the driver is going to access the caller's buffer on a thread that belongs to some other process, say the kernel, then it falls under asynchronous arena and the driver has to marshall the buffer using the marshalling APIs so that the kernel driver has a local copy of the buffer that can be accessed when needed on any thread

    The marshalling need here arises from the fact that you cannot be sure of the user process mapped when accessing the caller buffer on some other thread. And so, you have to marshal the buffer initially on the caller's thread to get a local copy for future use. The local buffer can then be accessed by any other driver thread and upon completion needs to call the right API to free up the local buffer and to copy back the buffer to the caller's process.

    Let me know if this helps - else I will put up some diagrams to illustrate this clearly

    3) Thank you for your kind words. And thank you for your patience in listening and understanding these complex concepts.

    4) Tongue Out
  • Hello  funkster--

    The number of drivers really depend on the CE Device you are building or refering to. But on the general, a CE device will have some Storage/block driver, some networking driver(s), probably an Ethernet Debug one, soemtimes USB and SD/SDIO, Audio for others and Display/Video for those with screens and soetimes with Touch for touch capability. In addition I have seen PCMCIA/PC Card, Keyboard, Mouse Input drivers, Serial/Parallel so you can see exactly how the average is so hard to define across the numerous different CE Devices.

    Is there any particular information you are tryign to gether that I might be able to help with?
  • Thanks, Juggs!

    I am into tech Quizzing, and was gathering information for upcomming quiz on Windows Embedded CE Big Smile.
    If i am not wrong any fresh WinXP installation with default hardware (USB, NIC etc.)will have around 200 drivers in its system folder and out of them only half of them are frequently used! So i was curious about devices with small footprints.

    BTW, Thank you once again and awesome video;)


  • Hi
        I am a beginner to win CE and i was searching for some stuff and got this video at the right time

    Gave me a good understanding of the basic concepts and many new terminologies in win ce .
    The way u explained things shows your love towards win CE and the work you guys have done for that... Smiley  good work juggs...



    -Raja.K

  • Hi Juggs
    Its really a helpful video for me as I am working with 5.0 and want to go for 6.0, One query I have is what I need to do if I am having a BSP for 5.0 and want to port it on 6.0. Can I import 5.0's BSP on 6.0 ( I guess its not possible).Please correct me if I am wrong & help me out...

    Thanks...
  • Hi Nitin

    I hope, our team, e-consystems.com, (www.e-consystems.com) can help you fix the problem, you can mail me on vsanghi@e-consystems.com with detailed query...

  • Porting 5.0 BSP's to 6.0 requires some work but its something that can be done quite easily. I will probably do a demo so that you get the overall picture of what was changed and how you can get your porting done right away.

    Thanks for the kind words
  • I got some feedback while I was in Vegas Big Smile attending MEDC 2007..

    I might not have been clear in my presentation but the CE 6.0 Kernel will validate first level pointer parameters for you. It knows the signature of the API (and can verify the first level buffer being passed to the kernel driver.

    You as a driver developer, only have to Access Check embedded pointers; embedded pointers are pointer parameters that are passed to your driver by storing them within the first level buffer - Actually you can view this recursively and can have nested buffers.

    The kernel while checking the first level parameter has no idea of what the 4 bytes stored with the buffer means to the driver - it could be a DWORD for all it cares; it all depends on how the kernel driver is going to interpret these 4 bytes - and thus, It is the responsibility of the driver to access check embedded buffers because such embedded buffers could be pointing to memory that the caller does not have access to.

    Kernel drivers would call CeOpenCallerBuffer API to access check embedded buffers before using them and when done, simply call CeCloseCallerBuffer as detailed at - http://blogs.msdn.com/ce_base/archive/2006/11/22/marshalling-helper-apis.aspx

    I hope that clarifies any issues on Access Checking.

  • Gr8 Video..!!
  • Ravalia, can you send me any demo or info how to porting 5.0 BSP's to 6.0? akolpakov@technocenter.ru
  • hi juggs
    i want to know tht if i just port my code from 5.0 to 6.0 then how could i identify tht my driver is loaded in kernel space or not
  • Hi, Juggs

    When the driver wants to access the embedded pointer asynchronously, the driver must follow what's rule for secure copy? Without secure issue, I'm sure I can use CeOpenCallerBuffer, and CeAllocAsynchronousBuffer to do that. But what to do if considering secure copy?
  • Thanks Raja - We surely have a great, hardworking team.
  • 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
  • I would look at the great presentation by Travis Horbla on Channel 9 on Porting BSPs -
    http://channel9.msdn.com/Showpost.aspx?postid=376154

  • 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
  • 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.
  • Jugs,

    A very good video!!

    I have a doubt, If I am running the Driver in Kernel Mode, Is it required by me to use CeOpenCallerBuffer for dealing with Embedded Pointers, Mostly for syncronous process(IOCTL cmd's).

    Can you give me a simple illustration of Asyncronous process in Drivers.

    -sync
  •  

    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.

     

Remove this comment

Remove this thread

close

Comments Closed

Comments have been closed since this content was published more than 30 days ago, but if you'd like to continue the conversation, please create a new thread in our Forums,
or Contact Us and let us know.