Inside Windows CE API Calls

re: Inside Windows CE API Calls

Dean Ramsier — Thu, 09 Feb 2006 07:57:31 GMT

Great description of the thunking process, I always had a general idea of what was going on but never saw a real description.

One correction, I believe that kernel mode threads do not have access to any memory address they like, they can only access the memory for their slot plus the kernel memory. Other user processes are still protected. The kernel can't trash the memory of another process any easier than a user mode thread can.

Any process (including the kernel) that wants to access the memory of another process must call SetProcPermissions to gain access to the virtual addresses in the slot.

- Dean

re: Inside Windows CE API Calls

Dean Ramsier — Thu, 09 Feb 2006 08:22:20 GMT

Correction to the above - the kernel can trash all physical memory via kernel virtual addresses, since all physical memory is mapped into kernel virtual address space. It just can't arbitrarily access any virtual address in user space below 0x80000000.

- Dean

re: Inside Windows CE API Calls

ce_base — Thu, 09 Feb 2006 16:56:09 GMT

Thanks Dean, you're right, I was being inaccurate when I said that kernel mode threads can access any memory they want. There is still address space protection for user mode virtual addresses. I *think* (but don't know for sure) that kernel mode threads are allowed to access all of the kernel virtual address space (over 0x80000000). And yeah that would mean that kernel mode threads could access all user mode memory via the static-mapped kernel address space, though they'd have a tough time figuring out the mapping between user mode address and static-mapped kernel address. In reality, any thread that's allowed to run in KMODE will also be allowed to call SetProcPermissions and access the user mode address directly. In KMODE the address space protection is more to catch accidental mistakes than intentional abuses. But, thanks for keeping me honest! ;-)

Sue

re: Inside Windows CE API Calls

Dean Ramsier — Thu, 09 Feb 2006 20:08:53 GMT

Kernel mode threads can access all kernel memory, that over 0x80000000. That's all that kernel mode really means, from a user point of view. The other benefits are under the hood performance, which you've described here.

Most people don't realize the difference between kmode and trust. In order for a thread to call SetProcPermissions (or SetKMode, or one of any number of other trusted APIs) the thread has to be trusted, not necessarily in KMode. Unless the OEM has done something to implement a trusted environment, all threads will be trusted, and all threads can move themselves in and out of KMode and independently call SetProcPermissions.

As you said, any thread in KMode can call SetProcPermissions, but that is because it could only have gotten into KMode if it was already trusted.

Maybe a blog on this topic sometime?

Keep up the good work!

- Dean

re: Inside Windows CE API Calls

ce_base — Thu, 09 Feb 2006 20:34:50 GMT

Good points, Dean, thanks!

Sue

re: Inside Windows CE API Calls

Charlie — Fri, 17 Feb 2006 03:30:30 GMT

Is generating an exception this way more efficient on ARM than a software interrupt? Or why was this method picked? Where can I learn more about the internals of Windows CE?

re: Inside Windows CE API Calls

ce_base — Fri, 17 Feb 2006 20:06:00 GMT

I don't know why this method was picked, actually. I think it's probably linked to the fact that we continue executing on the current thread rather than switch to a different thread inside the server process.

The best description of Windows CE internals that I know of is the book "Inside Microsoft Windows CE" by John Murray. It's a little dated by now, but it lays out the groundwork of what you'd need to know to understand what's going on inside the OS.

Sue

Books and other resources for learning about Windows CE

Windows CE Base Team Blog — Fri, 12 Jan 2007 09:02:37 GMT

Posted by: Sue Loh I am occasionally asked whether I know any good books or other resources to help learn

What is kernel mode?

Windows CE Base Team Blog — Thu, 01 Feb 2007 03:29:12 GMT

Posted by: Sue Loh I've talked about this before but I want to really highlight it because I still see