Comment Feed for Channel 9 - Juggs Ravalia – Windows CE 6.0 Device Driver Model

Re: Juggs Ravalia – Windows CE 6.0 Device Driver Model

LiQ — Fri, 08 Sep 2006 11:27:22 GMT

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...

posted by LiQ

Re: Juggs Ravalia – Windows CE 6.0 Device Driver Model

ravalia — Tue, 12 Sep 2006 03:48:35 GMT

Thanks LiQ for your comments

Let me know what needs further clarification if any and I will do my best to explain it better

posted by ravalia

Re: Juggs Ravalia – Windows CE 6.0 Device Driver Model

mjones — Wed, 04 Oct 2006 14:34:29 GMT

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

posted by mjones

Re: Juggs Ravalia – Windows CE 6.0 Device Driver Model

mjones — Sat, 07 Oct 2006 17:43:16 GMT

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.

posted by mjones

Re: Juggs Ravalia – Windows CE 6.0 Device Driver Model

funkster_smokey — Wed, 29 Nov 2006 13:05:17 GMT

Hi Juggs,

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

posted by funkster_smokey

Re: Juggs Ravalia – Windows CE 6.0 Device Driver Model

ravalia — Sun, 10 Dec 2006 00:39:35 GMT

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

posted by ravalia

Re: Juggs Ravalia – Windows CE 6.0 Device Driver Model

ravalia — Sun, 10 Dec 2006 01:02:24 GMT

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)

posted by ravalia

Re: Juggs Ravalia – Windows CE 6.0 Device Driver Model

ravalia — Sun, 10 Dec 2006 01:10:14 GMT

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?

posted by ravalia

Re: Juggs Ravalia – Windows CE 6.0 Device Driver Model

funkster_smokey — Thu, 14 Dec 2006 16:50:15 GMT

Thanks, Juggs!

I am into tech Quizzing, and was gathering information for upcomming quiz on Windows Embedded CE .
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;)

posted by funkster_smokey

Re: Juggs Ravalia – Windows CE 6.0 Device Driver Model

rajasekaran — Tue, 30 Jan 2007 05:43:41 GMT

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... good work juggs...

-Raja.K

posted by rajasekaran

Re: Juggs Ravalia – Windows CE 6.0 Device Driver Model

nitin_bharane — Tue, 30 Jan 2007 06:15:41 GMT

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...

posted by nitin_bharane

Re: Juggs Ravalia – Windows CE 6.0 Device Driver Model

sanghivivek — Sun, 18 Feb 2007 04:45:30 GMT

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...

posted by sanghivivek

Re: Juggs Ravalia – Windows CE 6.0 Device Driver Model

ravalia — Mon, 19 Mar 2007 09:52:08 GMT

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

posted by ravalia

Re: Juggs Ravalia – Windows CE 6.0 Device Driver Model

ravalia — Sat, 19 May 2007 04:03:46 GMT

I got some feedback while I was in Vegas 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.

posted by ravalia

Re: Juggs Ravalia – Windows CE 6.0 Device Driver Model

shrads — Wed, 17 Oct 2007 10:12:10 GMT

Gr8 Video..!!

posted by shrads

Re: Juggs Ravalia – Windows CE 6.0 Device Driver Model

Virtuoz — Mon, 04 Feb 2008 09:22:55 GMT

Ravalia, can you send me any demo or info how to porting 5.0 BSP's to 6.0? akolpakov@technocenter.ru

posted by Virtuoz

Re: Juggs Ravalia – Windows CE 6.0 Device Driver Model

victory — Thu, 06 Mar 2008 06:45:57 GMT

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

posted by victory

Re: Juggs Ravalia – Windows CE 6.0 Device Driver Model

jason jiang — Sun, 20 Apr 2008 14:06:41 GMT

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?

posted by jason jiang

Re: Juggs Ravalia – Windows CE 6.0 Device Driver Model

jayrava — Wed, 09 Jul 2008 18:59:53 GMT

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

posted by jayrava

Re: Juggs Ravalia – Windows CE 6.0 Device Driver Model

jayrava — Wed, 09 Jul 2008 19:01:55 GMT

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

posted by jayrava

Re: Juggs Ravalia – Windows CE 6.0 Device Driver Model

jayrava — Wed, 09 Jul 2008 19:03:01 GMT

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

posted by jayrava

Re: Juggs Ravalia – Windows CE 6.0 Device Driver Model

jayrava — Wed, 09 Jul 2008 19:10:16 GMT

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

posted by jayrava

Re: Juggs Ravalia – Windows CE 6.0 Device Driver Model

jayrava — Wed, 09 Jul 2008 20:10:59 GMT

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.

posted by jayrava

Re: Juggs Ravalia – Windows CE 6.0 Device Driver Model

sync — Wed, 09 Jul 2008 23:06:54 GMT

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

posted by sync

Re: Juggs Ravalia – Windows CE 6.0 Device Driver Model

jayrava — Thu, 12 Aug 2010 04:42:28 GMT

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.

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

Now let me answer the embedded pointer question.

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.

posted by jayrava