With CE 6's new kernel layout, the file system, the bulk of the drivers and GWES have been moved into the kernel. The kernel has also been restructured to allow better encapsulation from the OAL, and a number of actions have been taken to make the kernel more secure and robust. According to MS, the kernel performance compared to CE 5 can be summarized:

• size has increased less than 5%
• some performance gain in process switching is expected
• inter-process calls will have some overhead attached to it
• Thread switching, memory allocations and system calls will have about the same performance

Moving PSL:s into the kernel

In CE 5 part of the core functionality is implemented as sepparate processes, so called PSL:s or Process Server Libraries. The file system, the graphical window manager (gwes) and the device driver manager all run as separate processes in user space and register their API with the kernel. In CE 6, these servers have been integrated into the kernel and are instead loaded as dll:s by "oal.exe":

Before continuing it is important to sort out a few definitions. The concept of "kernel mode" as known from CE5 does not really exist in CE6. In Windows CE 5.0 and earlier, "kernel mode" is an access level attached to a thread.  If a thread is "in kernel mode" it can access kernel address space (0x80000000 and above).  In CE5 you’d call SetKMode to put your thread into (or out of) kernel mode at will.

In Windows CE 6.0 the implementation is pretty much the same, except that the SetKMode API is no longer supported.  What this mean is that you can no longer choose to put a thread into/out of kernel mode yourself. In CE 6.0, the basic rule is: your thread is in kernel mode while executing code inside the kernel process, like when calling most system APIs, and not in kernel mode when executing code inside a user process.

The term “kernel mode” is often used loosely, like when talking about "kernel mode drivers”, "kernel mode servers" and "kernel mode addresses." Whenever people use these phrases they're referring to code and addresses that are only accessible to the kernel process (address 0x80000000 and above).

Now, converting the PSL:s to kernel mode servers will greatly reduce the overhead of system calls between these components. By using a special kernel version of "coredll.dll" -"kcoredll.dll" -calls between the components don't have to go through the "thunk and trap" code the user space version had to. It will also reduce the overhead of API calls to these servers since many of the API calls don't have to switch process as many times as in CE 5,  and it opens up for increased code sharing between the kernel servers.

The downside is that moving these components into the magic land of kernel mode opens up for potential security and stability problems. As drivers now will run in kernel mode and thus have access privileges to all memory, a seemingly harmless driver may become a powerful tool in the hands of a hacker. So, in CE 6 it is more important than ever to know how to design well-behaved, secure drivers.

To give some protection against security vulnerabilities and/or system instability that untrusted- or poorly written drivers may cause, an option to load a driver in a user space mode instead of kernel mode has been implemented. This of course adds system call overhead to this driver since the kernel needs to switch processes, rather than just do a direct call into the driver.

Security and robustness

It is becoming increasingly popular for corporations to incorporate mobile or distributed solutions as part of their day-to-day business. With more and more sensitive information being hosted on, or accessed through, a mobile device the security of the device has become just as important as the security of a desktop system. So, making the new kernel as secure and robust as possible has been a top priority for Microsoft. Working with input from Microsoft's "Secure Windows Team", a number of areas have been addressed to improve the general robustness and to harden the kernel against potential security attacks:

• The parameter validation for system calls has been improved.
• Per-process page and handle tables - By not sharing handles over all processes, the risk of one process manipulating another process handles will be minimized.
• Secure stacks - To safeguard stack manipulation, system calls will now have their own kernel space stacks.
• Robust Heaps - The control structures now reside in a separate space from the heap data, rather than being interleaved with the heap data.
• Safe Remote Heaps for OS Servers - The new kernel allows OS servers to allocate heaps that can be made read only for client processes, which make them harder to tamper with, and also increases the overall robustness of the OS.

There has been a lot of work done to enhance security, but in one area, the trust model in CE 6, it almost feels like they have regressed a bit rather than improved. The trust model has been reduced to a two-level (1-tier) model. Either a module is trusted, or it is not trusted (not allowed to run at all). The reason for this seemingly reduced functionality is that Microsoft is moving away from the old trust model towards a privilege based ACL model, and the current implementation in CE 6 can be seen as an intermediate step towards the full implementation.

Per-process page tables

This is really a consequence of the new memory architecture. Since each process has its own page table, pointers are unique to each process, and you cannot access memory in another process without some cooperation from the other process.

Per-process handles

Each process has its own handle table in CE 6. This improves security since it is not possible for one process to directly tamper with another process' handle, as in CE5 and before. It also improves robustness much in the same way: In earlier versions a "sloppy application" might actually release handles for other processes by mistake. Say, for example that the process implements a chunk of code that does a release of the handle even if it has already been released. This might not seem like a big deal at first glance, but since all handles are shared among processes in CE 5, this particular handle once released by the "sloppy" process, may now be allocated by another process. When the sloppy process releases the handle the second time, it actually is messing up the other process. By giving each process its own handle table, this problem is eliminated. In addition, handles are now referenced and its usage is tracked so that applications or drivers can check that it is not still used by anyone before it closes the handle.

Introducing per-process handles also complicates things a bit. If you need to pass a handle between processes, you now need to allocate a process-specific copy, duplicate, of the handle before it is valid to use in your process' context.

Restricted physical memory mapping

In CE 5 a trusted user process could map physical memory. In CE 6 the VirtualCopy and it's related API:s have been restricted to kernel components. In other words, accessing physical memory from a user process now must be done by using a kernel mode driver as proxy. However, to allow user mode drivers to map physical memory the udevice.exe application architecture allows for mapping kernel space memory with some restrictions.

Loader

The loader is responsible for loading executables and dll's. The loader now uses an enhanced security model that uses encrypted signatures to validate files before they are loaded and executed. With this new secure loader, Microsoft has laid the foundation for a future code based security architecture, i.e. security is enforced based on what code is running, rather than who uses it (user based security).

Monotonic clock

The kernel now implements a monotonic clock - a clock that is only ticking up, and is independent of the user clock. This provides a secure and reliable way of calculating elapsed time.

Huge file support

Another feature that is maybe not directly connected to the kernel layout but nevertheless worth mentioning is that with CE 6 it is now possible to map "huge" files. The inability to effectively manage really big memory mapped files efficiently has traditionally made the development of applications that rely on huge data stores to operate a real hassle (such as geodetic devices with its digital maps, or set top boxes that store and replay video streams). With CE 6, this limitation is finaly removed.