Inside The Windows Pre-Boot Environment

1. Inside The Windows Pre-Boot Environment Andrew RitzDevelopment ManagerCore Platform Architecture TeamMicrosoft Corporation

2. Agenda • What is firmware (and how does Windows use it)? • Multi-OS Firmware roadmap for Windows • Windows Boot Environment overview • Deployment Guidelines for Boot Environment

3. What Is FirmwarePower on sequence • Installed with a computer in non-volatile location (PROM\EEPROM) • Initializes low level hardware • Initializes memory controller timings, powers on critical boot devices • Hands off control to operating system loader • Operating system loader uses firmware interfaces to initializethe operating system • Refer to as pre-boot firmware • Examples: BIOS and EFI

4. What Is FirmwareLimited runtime usage • Firmware may still be involved after operating system starts • This is called runtime firmware • Operating system normally strives to place runtime firmware into a sandbox for reliability • An exception is System Management Mode (SMM) firmware • Firmware is used in cases where a high-performance WDM driver does not exist • Handles some of the specifics of a particular platform running Windows

5. What Is firmwareLimited runtime usage • Advanced Configuration and Power Interface (ACPI) defines an industry standard for runtime firmware • Primary supported runtime firmware interface for Windows • Microsoft co-authored industry standard ACPI specification • Used to identify and configure ‘soldered on motherboard’ hardware and more • Asynchronously notifies operating system of changes inhardware (e.g., when a laptop switches from AC tobattery power) • Firmware runs in an OS-provided virtual machine

6. BIOS Firmware (aka PC/AT)De-facto boot firmware standard • Mechanism used to boot PCs for the last 25+ years • All x86/x64 Windows machines on the market support BIOS firmware • BIOS is a real mode environment • 16-bit real-mode interfaces • BIOS showing its age • Over twenty five years old • Documentation is scattered • Interfaces have evolved in an ad hoc manner as technical advances exposed limitations • Example: Interfaces to read data from hard drive • Implementations are not always consistent • 16-bit real mode complexity (getting compilers, staffing engineers, supporting 64-bit systems)

7. BIOS Firmware (aka PC/AT)Windows usage and limitations • Windows uses BIOS as pre-boot firmware • Exception is emulation of Video BIOS • Sometimes relied upon by video driver at runtime • Windows Display Driver Model (WDDM) disallows Video BIOS (int 10h) usage by OS Driver • Strategy: Migrate away from any 16-bit code usage over time

8. EFI FirmwareMotivation and history • EFI creation motivated by Itanium bring up • Desire to avoid BIOS limitations in a brand new high end architecture • Also designed as a BIOS replacement • Avoids BIOS pitfalls • Modern design incorporates twenty five years of progress in computer science • Runs in native processor mode • Can be programmed in C/C++ • More accessible than BIOS • Well specified; largely in one self-contained document • Architecture is modular and extensible • EFI Interfaces are object oriented • For example, Block IO Protocol contains a ‘base class’ for reading from any block IO device • Interfaces should be consistent by virtue of EFI conformance test

9. EFI FirmwareWindows usage • Windows uses EFI as pre-boot firmware • Some limited runtime interfaces used • Mainly to manipulate NVRAM boot entries • Windows has supported EFI for several years • First supported in EFI 1.02 Itanium systems for Windows Server 2003 • Challenge: How to achieve EFI adoption in mainstream PC client and server systems

10. Transition From EFI To UEFIMainstream 64-bit computing inflection • The emergence of x64 provides an inflection point to begin industry-wide transition to EFI • To encourage transition Microsoft helped champion the formation of the Unified EFI (UEFI) Forum • Broad industry forum with common goal • UEFI version 2.0 published in February 2006 • Forum members with common goal allowed engineers to focus on technical details

11. Key changes: EFI To UEFI64-bit native firmware • UEFI nearly identical to EFI 1.10, but thereare a few key differences • X64 required some changes to EFI specification • Runtime calls must run in same modeas operating system; for native EFI boot, • A 64-bit operating system requires 64-bit UEFI firmware • A 32-bit operating system requires 32-bit UEFI firmware • Architectural changes for Video BIOS

12. Windows Firmware Roadmap Goals • Enable mainstream 64-bit computing • Achieve firmware independence • Consistent with Windows portability goals • Transition away from BIOS firmware to EFI firmware over time • The removal of BIOS architectural barriers will enable new scenarios over time • Avoid jarring changes during this transition • For deployment • For system management • For end users

13. Windows Firmware Requirements • Parity support for all scenarios on BIOS and UEFI systems • Support UEFI on mainstream x64 systems • Support boot of older operating systems on UEFI platforms • UEFI does support a firmware compatibility layer to support boot of prior BIOS-based operating systems • UEFI transition requires industry-wide effort • This takes some time, and someone must take the first step • Microsoft helping lead the transition • Working with IBVs, IHVs, OEMs, ODMs, OSVs

14. Windows Firmware RequirementsSimplifying the UEFI transition • Firmware footprint for both 32-bit and 64-bit UEFI implementations on same machine is cost prohibitive • In Windows Vista timeframe, nearly all processors are 64-bit capable • 64-bit computing is the wave of the future • Focusing on 64-bit UEFI achieves our goals • Little motivation to support 32-bit UEFI boot • Too few 32-bit only processors in new platforms • Avoid any assumptions about firmware and bootstrap in larger base of 32-bit drivers

15. UEFI Support For Windows Server Longhorn • Microsoft will support X64 and IA64 UEFI boot for Windows Server Longhorn • Coincides with the timeframe when heterogeneous mix of production quality UEFI firmware should be available for broad based consumption • EFI 1.10 support continues for current IA64 systems • 32-bit UEFI support is currently not part of our long term client and server roadmaps • 32-bit systems must boot Windows via BIOS • A firmware compatibility module may be used in the transition

16. Firmware Support Roadmap Reference KEY: Yes, logo: Can be used and is also a requirement in order to get a Designed for Windows logo for that OS release on that architecture Supported: Can be used but is not the only choice for that OS release on that architecture Unsupported: Cannot be used for that OS release on that architecture Required: The only choice for that OS release on that architecture

17. UEFI Firmware Support • Windows Vista Beta 2 will have UEFI support available for test and development • Includes x64, IA64 support • Partners can make EFI CD media manually • Contact us for instructions • Post Windows Vista Beta 2 • x64 UEFI support removed for Window Vista RC, RTM • UEFI support will be present in Windows Server Longhorn Beta and RTM • UEFI support will be re-added in subsequent Windows Vista release

18. Future Windows Firmware Support • Windows Server Longhorn wave has feature parity across BIOS and UEFI • If widespread adoption occurs, Windows direction is to begin adding value to UEFI based platforms in future releases • Exclusive support for new scenarios and experiences • Will add support for VGA-less graphics platforms

19. Windows Vista And FirmwareBuilding block for firmware independence • Earlier versions of Windows based upon Advanced Risc Computing (ARC) boot firmware specification • Used by ntldr program and portions of Windows kernel • Internally, data was represented in ARC format • Taking a new approach for Windows Vista • With emergence of UEFI, taking opportunity to begin transitioning Windows Vista and beyond to be boot firmware independent • This is consistent with the portability goals of the Windows platform • A more robust approach that should survive for many years

20. Windows Vista And FirmwareBuilding block for firmware independence • Boot Environment architected from the ground up for Windows Vista • Firmware independence allows for cleaner layering • Enables support for a wide range of new features; a sample of these features includes • High resolution graphics • Extensible boot device support • Programmatic boot configuration

21. A Look At The Internals

22. Pre-Boot Usage ModelComponent architecture • Windows pre-boot library • Abstracts pre-boot firmware interfaces • Example: Pre-boot device access uses data structure abstraction • Windows pre-boot applications • Applications that link to Windows pre-boot library

23. Pre-Boot Usage ModelWindows pre-boot applications • Windows boot manager • The first Windows pre-boot application launched • Purpose is to launch other Windows pre-boot applications • Exposes Windows specific boot options • One windows boot manager per machine • Different than the UEFI boot manager • OS loader • Tied 1:1 to the OS (unlike NTLDR) • Resume loader • Tied 1:1 to the OS • Windows memory diagnostic • Includes integrated end-to-end scenarios

24. Pre-boot ConfigurationBoot Configuration Data (BCD) • Windows Vista introduces BCD data store • Abstracted data store • Replacement for boot.ini • Replacement for NVRAM settings • BCD is a container for BCD objects • A BCD object represents a pre-boot application • One object for Windows boot manager, another for Windows OS loader • An application option is represented as an element of a BCD object • Programmatic access • Accessible via utilities and WMI provider • Fully documented on MSDN

25. Pre-Boot ConfigurationBCD system store • Each machine has a BCD store designated as the system BCD store • Present on the active system partitionon BIOS systems • Present on ESP on UEFI systems • System store is created and initialized by the setup process

26. Pre-Boot User ExperienceAvoiding end user confusion • Transition to UEFI firmware should not be jarringto end users • Differences between UEFI and BIOS environmentsare abstracted from the end user wherever possible • Example • UEFI systems uses NVRAM for Windows Boot Manager only • BCD is used for everything else • BCDEdit.exe works on either system and abstracts the differences • Common DVD media for UEFI and BIOS platforms

27. Pre-Boot User ExperienceWindows boot manager • Default user experience optimized for a single OS install • Vast majority of the customer base • Set the EFI boot manager timeout to zero, set default boot application to Windows boot manager • If only one OS installed, no pre-boot UI presentedto end user • OS Loader can run in < 2 seconds so user won’t notice • If an error occurs on previous boot, user presentedwith localized troubleshooting UI

28. Pre-Boot User ExperienceMulti-boot experience • If multiple Windows OS’s installed, Windows boot manager is presented to user • Windows boot manager runs in user’s preferred locale • Locale may not be the same as the UEFI boot manager • Localization support depends upon firmware graphics support

29. Pre-Boot User ExperienceRich graphics support • Windows Boot environment supports 32-bit high resolution graphics • Used both for displaying bitmaps and for displaying localized glyphs • No color palette support, must be full 32-bit color • BIOS platforms must support VESA bios extensions: Either 1024x768 or 800x600 (32-bit linear frame buffer) • EFI platforms must support either UGA or UEFI Graphics Output Protocol (GOP) • UGA can be used for existing implementations • Long term direction is to use GOP

30. UEFI Installation • To install via UEFI requires that the installationbe booted via UEFI • And vice versa – an OS installed via BIOS can only boot via BIOS • The OS installer must • Configure the EFI System Partition (ESP), including the BCD store • Use the EFI runtime services to set the NVRAM optionsfor Windows Boot Manager • Once the OS is installed via UEFI it can only boot via UEFI • Booting via BIOS cannot access the BCD store on the ESP • Features like BitLockerTM require the same boot process each time the system boots

31. Deployment GuidelinesCD/DVD boot • Windows Server Longhorn media will contain both BIOS and UEFI bootstrap code • A BIOS system should boot via BIOS • An x64 or IA64 UEFI system should boot via EFI • A system with both UEFI and BIOS support should boot via UEFI • Such systems should never prompt the user to boot via UEFI and BIOS

32. Deployment GuidelinesIdentifying disks • Windows Boot Environment uses disk signatures to identify partitions on disks • Avoids ambiguity of firmware enumeration dependencies • Always ensure a unique disk signature is present on disks • A special consideration to make for disk duplication • Special cases • Special designation for the boot partition • For un-partitioned disks, boot loader will not stamp disk signature • User must partition disk • A reboot may be necessary

33. Deployment GuidelinesConsider implementing system partition • BIOS deployments should create separate system partition and Windows partition • The system partition is the partition marked active in the MBR • Referred to as the boot partition • Many OEM systems already have a recovery partition as well • This takes that process one step further • Architecturally clean and successfully used with prior implementations • Digital Equipment Corporation (DEC) Alpha support, Itanium EFI support • Provides isolation • End users do not need to access the system partition manually and likely won’t even notice • The BCD tools abstract away any need to access the system partition

34. Deployment GuidelinesConsider implementing system partition • Required for BitLockerTM support • Required to enable sysprep migration between EFI and BIOS systems • Enables transition to UEFI systems which will require two partitions • Note: The EFI system partition is hidden

35. Deployment GuidelinesSystem partition guidelines • Minimal state should be on system partition • Windows Boot manager • BCD store • No OEM state for an install of Windows should be on system partition • Boot partition designation cannot be used on multi-partition systems • Deployment tool needs to set the proper partition device identifier for target system

36. Deployment GuidelinesBCD deployment • Do not manually copy the BCD store onto systems • Use import functionality or let Setup create it • If you want to apply a setting to all objects, consider the power of inherited objects • See MSDN for details • The BCD WMI provider provides very rich capabilities • While BCDEdit.exe is very capable for many tasks, consider scripting with WMI for greater flexibility

37. Summary • Windows supports a variety of firmware and has long been a leader in driving industry innovation • Windows firmware roadmap includesa non-jarring transition to UEFI • Windows Boot Environment internals re-architected for this transition • Consider how to deploy Windows Vistafor optimal user experience

38. Call To Action • Get involved in the transition to UEFI • Try out the beta UEFI support • Test out the BCD infrastructure • Much more flexible than the boot.ini support • Evaluate when you are making the UEFI transition • OEMs: Please send evaluation systems and let us know what you think • ISVs: Stay tuned for industry enablement events

39. Additional Resources • Web resources • Microsoft Platform Design Portal (whitepapers, documentation): http://www.microsoft.com/whdc/system/platform/default.mspx • UEFI specification: http://www.uefi.org • For questions about boot support in Windows, contact Microsoft at: Winboot @ microsoft.com

40. Backup

41. EFI FirmwareGreat for the industry • Standards-based • Well-specified and unambiguous • Conformance testing means cross-platform consistency • Robustness • GPT support adds more fault tolerance • Security • NVRAM entries to launch a boot option; no MBR bootstrap  no MBR Viruses • Speed • Quicker hand-off from firmware to the Windows Boot Manager possible on Server systems • Architecturally clean and modernized • A native 64-bit firmware implementation for 64-bit processors • Take advantage of newer compilers and languages • Eases bring up • Modular design speeds implementation bring up • Eliminates BIOS complications • Eliminating the need for shadow memory enables more plug-in cards in a system • Server RAID option ROMs are very large and a single card may exhaust shadow memory • No 16-bit code

42. Booting From Optical Media • Windows shipping on optical media that can boot either via EFI or BIOS is planned • El Torito multiple boot catalog support is used to enable this • Default boot entry: BIOS ETFS bootstrap code • x86 platform tag • Launches BIOS bootstrap code “etfsboot.com” • Second boot entry: EFI boot application • EF platform tag • Points to a mountable file system containing \EFI\BOOT\BOOTX64.EFI • For this to work the BIOS must support multiple boot entries, and should default to booting the default entry

43. Booting From Optical Media • EFI ignores the BIOS entry and recognizes the EFI entry • It mounts the ESP and launches the boot application • Windows is planned to support both CD and DVD/UDFS boot • UDFS also uses El Torito, and is built using the UDFS bridge format

44. © 2006 Microsoft Corporation. All rights reserved. Microsoft, Windows, Windows Vista and other product names are or may be registered trademarks and/or trademarks in the U.S. and/or other countries. The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information provided after the date of this presentation. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.