EMB320 Windows CE 5.0

Image Configuration, Boot Loaders, And Security

Jeff Glaum, Software Development Manager Glen Langer Program Manager Windows CE Core OS Team Microsoft Corporation

D L H C ardware/ D evice B uilding T ools L ightweight R elational N ative & M M M S D M rivers anaged erver S ide ultimedia ocation S ervices evelopment T ools ommunications essaging anagement T ools OEM/IHV Supplied BSP (ARM, SH4, MIPS) Platform Builder OEM Hardware and Standard Drivers Standard PC Hardware and Drivers Windows XP DDK Windows Embedded Studio EDB SQL Server 2005 Mobile Edition Win32 MFC 8.0, ATL 8.0

SQL Server 2005 Express Edition SQL Server 2005 .NET Compact Framework ASP.NET Mobile Controls .NET Framework ASP.NET

Windows Media DirectX MapPoint Image Update Visual Studio 2005 Internet Security and Acceleration Server Exchange Server Live Communications Server Speech Server Device Update Agent Software Update Services Systems Management Server Microsoft Operations Manager

Agenda

Introduction Memory and Storage Technologies Windows CE 5.0 Image Configuration Building an Image Boot Loaders Boot Loader Security Resources MEDC Call to Action Q and A

Introduction

Design Trade-Offs Image storage SRAM, Flash (NOR & NAND), or Disk Execution Execute in Place (XIP) versus Relocatable Slower and cheaper versus faster and $$ Compression Smaller image size (save cost) vs. slower loading but faster execution Boot Loader Complexity versus Performance Security How does Windows CE support this?

Build process and tools

Agenda

Introduction Memory and Storage Technologies Windows CE 5.0 Image Configuration Building an Image Boot Loaders Boot Loader Security Resources MEDC Call to Action Q and A

Memory And Storage Technologies

Type significantly impacts cost and performance Each technology imposes different design constraints Note: The data for this section was derived from leading vendor publications for both NAND and NOR; Because of ongoing changes in flash memory technologies, this information is subject to change

NAND Flash Memory

Dates from the late 1980s Generally offers a lower cost per byte Higher storage capacity Block-accessed storage device with a serial interface Block-access method makes NAND unsuitable for execute in place (XIP) Images typically moved to RAM for execution

NAND Flash Memory

Issue: Where does CPU access code from for initial pre-boot or for OS at boot time?

Solutions Add NOR flash Use Hybrid flash New CPU designs use serial interface Issue: Susceptible to manufacturing flaws and possible run-time cell failures Solutions Hardware and/or software data error checking and correction logic (ECC) Wear-leveling techniques to limit number of erase cycles

NAND Flash Memory

Generally has shorter erase and write access times Comparable read access time Trade-Offs Lower cost-per-byte ratio and larger storage capacity, versus Additional system complexity and any additional expense in DRAM

NOR Flash Memory

Generally offers a higher cost per byte Storage capacity is typically smaller Random-access storage (linear) device with an SRAM-like interface Lack of manufactured bad blocks Suitable for XIP (execute in place) designs

NOR Flash Memory

Slower read times compared to DRAM Offset by optimizing code for cache usage Offset by running high-impact code from RAM (80/20 Rule) Trade-Offs Higher cost-per-byte ratio and smaller capacity, versus Lower system cost - no additional DRAM or bad block management logic

Hybrid Flash Memory

Combines the best of both NAND and NOR technologies on a single device NAND flash with on-chip wear-leveling and SRAM-like interface NAND flash with a NOR boot flash memory region for XIP

ATA/IDE Hard Disk Drive

Hard disk drive is good option for image storage Block-accessed devices Code must first be copied to linear memory (DRAM) for execution Trade-Offs Significantly longer read and write access times, versus Larger storage capacity

Agenda

Introduction Memory and Storage Technologies Windows CE 5.0 Image Configuration Building an Image Boot Loaders Boot Loader Security Resources MEDC Call to Action Q and A

XIP Versus Relocatable Code

Position independent or “relocatable” code OS loader adjusts references to addresses Efficient use of system RAM Load times are slightly longer for “fixups” Relocatable code Trade-Offs Less flexibility (only executes from RAM) Typically requires more RAM than XIPing from flash Faster execution Slower boot times

XIP Versus Relocatable Code

Fixed position or “execute in place (XIP)” Image is built to run from a specific location Location must support linear access XIP Trade-Offs Minimized RAM usage, versus Slower execution Faster boot times

Image Compression

Build tools control which components are XIP and which are relocated Commonly compressed to minimize flash usage Performance critical code Rarely used modules Trade-Offs Faster execution, versus Longer load times, versus Efficient flash usage

Agenda

Introduction Memory and Storage Technologies Windows CE 5.0 Image Configuration Building an Image Boot Loaders Boot Loader Security Resources MEDC Call to Action Q and A

ROM Image Builder

OS image is created by the ROM image builder tool (romimage.exe) Romimage.exe runs at the end of the build process (after all image components have been created/linked) Configurable binary image builder (.bib) files direct the process

ROM Image Builder

Romimage.exe performs the following functions Collects all the components that make up the final image: drivers, executables, and data files Adjusts code addresses (“fix-ups”) as necessary to control placement of the executable code in the image’s virtual address space Compresses parts of the image Places any data files or compressed sections in unused “holes” in the image (compact image) Generates the image - nk.bin

Binary Image Builder File

The binary image builder (.bib) file is a text file containing sections MEMORY: describes the embedded device’s memory map MODULES and FILES: describes the modules/files that are to be placed in the final image and their attributes (compressed, etc.) CONFIG: describes general image configuration information The .bib file (ce.bib) is generated from a number of individual .bib files (common.bib, project.bib, platform.bib)

CE Memory Architecture

Slot 0 – current process and consecutive code-data section DLLs Slot 1 – separate code-data sections (roughly 32MB) 0x8000.0000 – 0xFFFF.FFFF is the kernel virtual address range

.BIB – MEMORY Section

MEMORY section, specified in config.bib, details the system virtual addresses available NK 80001000 01FFF000 RAMIMAGE RAM 82000000 01DB0000 RAM RAMIMAGE entry locates any executables, modules, data files and compressed sections in the range of virtual address 0x8000.1000 through 0x81FF.FFFF (could be flash or RAM) RAM entry specifies the range of virtual addresses available to the Windows CE kernel for allocation to the file system or object store, process virtual address spaces such as heaps and stacks, memory mapped files and writable data sections

.BIB – MODULES Section

MODULES are fixed-up to a virtual address range (slot address) by romimage.exe

MODULES section identifies which executable files are to be included and their attributes INIT.EXE $(_FLATRELEASEDIR)\INIT.EXE NK SH MYDLL.DLL $(_FLATRELEASEDIR)\MYDLL.DLL NK SHC Each entry: module name (in image), file on development system, section name, and attributes Uncompressed code can XIP and is fixed up to run in slot 1 by default

.BIB – FILES Section

FILES section is similar to MODULES section however all entries are compressed by default and files aren’t fixed-up Used for data files (examples: bitmaps) PIC.BMP $(_FLATRELEASEDIR)\PIC.BMP NK SH Executable DLLs in the FILES section are loaded into Slot 0 (different from MODULES section) and reduce overall process address space globally

.BIB – CONFIG Section

Contains generic image configuration information ROMOFFSET – used to “move” RAM image into flash ROMSTART, ROMSIZE, and ROMWIDTH to .bin file) – used to create binary .nb0 file (in addition Other settings

Image BIN File Format

IMAGE HEADER 15 Bytes: 4230303046460A - 7 byte sync record 4 byte starting address of image (physical address in this case) 4 byte overall length of image IMAGE RECORD HEADER 12 Bytes: 4 byte address of record (physical address in this case) 4 byte length of record 4 byte checksum of record Image Start = 0x00220000, length = 0x00B52D90 Record [ 0] : Start = 0x00220000, Length = 0x00000010, Chksum = 0x00000829 Record [ 1] : Start = 0x00220040, Length = 0x00000008, Chksum = 0x00000314 Record [ 2] : Start = 0x00221000, Length = 0x0003EFFC, Chksum = 0x019B93D5 Record [ 3] : Start = 0x00261000, Length = 0x000003A0, Chksum = 0x00014AD3 ...

Record [119] : Start = 0x00000000, Length = 0x0022A178, Chksum = 0x00000000 start address

Image Mapping

At run time, OS components are fetched from the addresses chosen by Romimage.exe at build time Compressed modules must be copied into RAM Uncompressed modules will run XIP and will be mapped from the address range specified in the MEMORY section of the .bib file If the entire image is built to XIP from RAM but is stored in flash, then code is required —boot loader or early OS startup code —to copy the image to the correct RAM location

Agenda

Introduction Memory and Storage Technologies Windows CE 5.0 Image Configuration Building an Image Boot Loaders Boot Loader Security Resources MEDC Call to Action Q and A

Boot Loader Overview

The primary function of the boot loader is to load an executable image (OS) into memory and to run it Design is affected by Hardware choices (flash): XIP versus copy-to-RAM Manufacturing/process requirements: download transport Typical variations Load mechanism: Ethernet, USB, serial, local storage (flash, HDD, DOC, CF, etc.) or other Development versus production requirements OS image requirements (ex: XIP or compression)

x86 Boot Loaders

Special considerations real-mode (OS starts in protected mode) boot from disk (BIOS) x86 Boot Loader Variations LoadCEPC.exe – real-mode DOS program Eboot.bin – Ethernet boot loader Sboot.bin – Serial boot loader BIOSloader – uses BIOS INT13h interface ROMboot – replaces BIOS and supports IDE and Ethernet Future: PXE (network boot)

Development Process

Create development boot loader Downloads image from Platform Builder Later enhanced for production boot loader is cross-compiled, linked, and located on a desktop PC Downloaded and debugged on the target device JTAG / IEEE 1149.1 (debug board) Built-in ROM monitor EEPROM / Flash programmer Goal: share code with OS image (OAL)

Build And Output Format

Code located at %_WINCEROOT%\public\common\oak\drivers\ethdbg %_TARGETPLATROOT%\src\bootloader\eboot (links executable) – OEM code Boot Loader EXE run through romimage to generate BIN and possibly NB0 or SRE files BIN: download with Platform Builder (ROMOFFSET) NB0: JTAG/manufacturing SRE: requires interpreter on device (boot monitor)

Development Loader Design

Support libraries provided by Microsoft Common loader framework: blcommon Network and flash support libraries Goal is to minimize amount of code that needs to be written by OEM/partner Architecture designed to be modular and extendable

Boot Loader Architecture

Typical development boot loader blcommon OEM code eboot … bootpart flash FMD EDBG drivers

Boot Loader Architecture

Blcommon – generic boot loader framework OEM code – general board init and extensions Eboot – Ethernet functions (UDP, DHCP, TFTP) EDBG drivers – Ethernet drivers 3Com 3C90x, AMD AM79C97x, CS8900A, NS DP83815, NE2000, RealTek RTL8139, SMSC9000 and SMSC100 (list is growing) Bootpart – storage partition management FMD – flash management driver Samsung/Sandisk (NAND), Intel StrataFlash (NOR)

Boot Sequence

Boot loader startup sequence Startup EbootMain BootloaderMain OEMDebugInit OEMPlatformInit OEMPreDownload Download Occurs OEMLaunch Other (optional): OEMReadData OEMShowProgress OEMIsFlashAddr OEMMapMemAddr OEMStartEraseFlash OEMContinueEraseFlash OEMFinishEraseFlash OEMWriteFlash Kernel startup sequence Startup KernelStart ARMInit OEMInitDebugSerial OEMInit KernelInit HeapInit InitMemoryPool ProcInit SchedInit FirstSchedule SystemStartupFunc

Boot Process

CPU initialization: StartUp() Assembly code that runs at the CPU reset vector Initializes CPU core (RAM accessible) Protection mode (supervisor) Clocks/PLLs RAM controller Optionally sets up MMU and caches Relocates to RAM (and copies initialized global variable section) Initializes stack pointer Jumps to C code (blcommon entry point)

Boot Process

OEMDebugInit() Initializes debug output connection (example: serial UART) OEMWriteDebugByte() sends ASCII characters over debug output connection OEMPlatformInit() Initializes bridge (host, PCI, PCMCIA, etc.) and peripheral bus logic Initializes other board-level logic needed to access download transport hardware (example: Ethernet controller)

Boot Process

Pre-download initialization: OEMPreDownload() Prepares and establishes download connection For a development Ethernet boot loader, most of this handled in the eboot library’s EbootInitEtherTransport() and EbootEtherReadData() functions Obtain an IP address (static or DHCP) Broadcast UDP “BOOTME” packets on the subnet Jump to a device-resident image based on Platform Builder settings ** or ** Establish a TFTP connection to Platform Builder and download BIN file records

Boot Process

Post-Download/Lauch: OEMLaunch() Acquires user settings from Platform Builder (examples: clean boot, passive KITL, etc.) – handled in eboot library’s EbootWaitForHostConnect() function.

Fills out shared OS data structure (bootargs/driver-globals) Optional: writes download image to flash Jumps to image

Optional Functions

Flash-related OEMIsFlash() Checks whether an address is in flash OEMMapMemAddr() Maps BIN records to another memory range (useful for caching a flash image in RAM) OEMStartEraseFlash() OEMContinueEraseFlash() OEMFinishEraseFlash() OEMWriteFlash() Use BootPart and FMD for flash access

Boot Loader Security

Blcommon contains simple signature support Before writing a download image to flash and before running image, CheckSignature() called Signed hash of image’s table-of-contents (TOC) is stored in the .bin image

Agenda

Introduction Memory and Storage Technologies Windows CE 5.0 Image Configuration Building an Image Boot Loaders Boot Loader Security Resources MEDC Call to Action Q and A

Boot Loader Security

Chain of Trust Detecting and correcting errors During download During boot Prevention Locking the flash part Hardware interlocks

Boot Loader Security

Possible solutions using hardware ARM TrustZone ™ MIPS32 ® 4KSd ™ Core

Boot Loader Security ARM TrustZone

™ Normal Secure -TrustZone SW Elements Normal OS app.

Secure services Normal OS Licensable SW from ARM Boot Loader Secure Kernel Secure drivers & hardware abstraction layers Secure devices / peripherals ARM TrustZone TM diagram used with permission

Boot Loader Security ARM TrustZone

™ TrustZone ™ Advantages Secure Process Execution Secure mode for boot loader and kernel Periodically verify the image Secure Storage Public and private keys Cryptographic algorithms Sensitive data Secure peripherals Timers, smart card Trusted I/O, including JTAG access disabled ARM TrustZone TM info used with permission

Boot Loader Security MIPS32

®

4KSd

™

Core

Builds on MIPS’ existing server-class security (in all cores) MIPS32™4KSd™ Smart Card Core EJTAG Security features Instruction Cache Co-Processor Adds Secure MMU Secure Caches Cryptographic Acceleration Tamper Resistance Execution Core MIPS16e™ Code Compression Required Secure MMU TLB Secure Cache Controller Data Cache and/or Scratchpad Optional or Configurable BIU Power Management Security MIPS32® 4KSd™ diagram used with permission On-Chip Bus

Boot Loader Security MIPS

®

MT ASE

MIPS Multi-Threading presents Virtual CPUs Known as Virtual Processing Elements (VPEs) Could employ a software supervisor to enforce inter-VPE communication (or lack thereof) Apps MT Application-Specific Extension (ASE) also presents hardware Threads Known as Thread Contexts (TCs) Dramatically increase processor efficiency by instantly switching away from blocked threads OS Secure Kernel VPE0 VPE1 MT ASE MIPS Core MIPS® MT ASE diagram used with permission

Resources

“System Memory Management in Windows CE .NET”, whitepaper http://msdn.microsoft.com/library/en us/dncenet/html/systemmemorymgmtwince.asp

Platform Builder documentation, “ How to Develop a Boot Loader ” http://msdn.microsoft.com/library/default.asp?url=/li brary/en us/wcehardware5/html/wce50howHowtoDevelopaBo otLoader.asp

While At MEDC 2005…

Fill out an evaluation for this session Randomly selected instant WIN prizes!

Visit the Microsoft Product Pavilion in the Exhibit Hall Shorelines B Use real technology in a lab Instructor led Reef E/F & Breakers L Self-paced Reef B/C

After The Conference…

Build Install Build Join Full-featured trial versions of Windows CE and/or Windows XP Embedded Cool stuff & tell us about it: msdn.microsoft.com/embedded/community Windows Embedded Partner Program: www.mswep.com

Develop Install Enter Join Windows Mobile 5.0 Eval Kit including Visual Studio 2005 Beta 2 Mobile2Market Contest and win up to $25000: mobile2marketcontest.com

Microsoft Solutions Partner Program: partner.microsoft.com

Tools & Resources

Websites Newsgroups Blogs Tools Build msdn.microsoft.com/ embedded microsoft.public.

windowsxp.embedded

windowsce.platbuilder

windowsce.embedded.vc

blogs.msdn.com/ mikehall Develop msdn.microsoft.com/ mobility microsoft.public.

pocketpc.developer smartphone.developer dotnet.framework.compactframework

blogs.msdn.com/ windowsmobile vsdteam netcfteam Windows CE 5.0 Eval Kit Windows XP Embedded Eval Kit Windows Mobile 5.0 Eval Kit

Questions?

© 2005 Microsoft Corporation. All rights reserved.

This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.