Monday, June 2, 2008

WinCE 5 vs WinCE 6 ^_^

This is reference to http://www.e-consystems.com/WindowsCE5vs6.asp

The major changes in 6.0 are
  • Process address space is increased from 32MB to 1 GB.
  • Number of processes has been increased to 32K from 32.
  • User mode and kernel mode device drivers are possible.
  • Device.exe, filesys.exe, GWES.exe has been moved to Kernel mode.
  • SetKMode and set process permissions not possible.
  • System call performance will improve.
And here is the details:

- It supports safe SEH for security compliance (/GS)
- Secure C Run-Time Libraries
- PREfast support for ARM, MIPS, and SH
- Increase from 32 to 32,000 processes on the device
- Instead of a single 2GB VM for all processes now 2GB per process
- Separation of user and kernel mode space
- File system can support data encryption
- Added 802.11i support for WPA2 compliance
- Windows Media DRM 10 PD and ND
- Graphic windowing and events subsystem (GWES)
- Networking (TCP/IP, IPv6)
- Expanded file system
- More device drivers
- Critical OS components moved into kernel space (critical drivers, file system, and graphical window manager into the kernel)
- New shared heap (R/W for kernel R/O for user land)
- 1GB per process space
- New operating system layout
- In-depth security review of: System calls, Handles, Exception Handling, Memory Allocation, Loader,
- Improved parameter validation for system calls
- Per-Process page and handle tables - greatly improves process isolation, Improves code robustness
- System calls run on special kernel side stacks
- Safeguards system calls from stack tampering
- Heap control structures separated from heap data
- Safe Remote Heaps for OS components
- OS servers can open heaps in user process
- R/W for servers, R/only for user
- Performance optimization and safety from tampering
- Support for secure boot loaders
- Public / private key based
- Based around file signing
- Features supported in hardware (partial list)
- On-chip, tamper-resistant boot ROM
- On-chip RAM (secure key storage)
- Cryptographic support
- JTAG can be disabled
- Fusible or one-time programmable elements
- They acknowledge if JTAG is enabled, it all "falls apart"
- There are more complex attack scenarios that require secure PCB design to mitigate
- Embedded (nested) pointers and how they can be used for attack, such as:
- Pass an embedded pointer to some kernel address space and ask the driver to read/write to the addressed buffer, thereby potentially modifying the kernel
- There is a lot of emphasis around validation to mitigate this
- The kernel will perform parameter pointer validation
- It’s down to the API to perform embedded pointer validation
- The thread permissions model has changed in drivers
- There is strong emphasis on copying the "callers buffer" and then using that copy, as opposed to using the callers buffer itself