Inside The Windows Pre-Boot Environment

Andrew Ritz Development Manager Core Platform Architecture Team Microsoft Corporation

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

What Is Firmware
Power 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 initialize the operating system

Refer to as pre-boot firmware

Examples: BIOS and EFI

What Is Firmware
Limited 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

What Is firmware
Limited 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 in hardware (e.g., when a laptop switches from AC to battery power) Firmware runs in an OS-provided virtual machine

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)

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

EFI Firmware
Motivation 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

EFI Firmware
Windows 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

Transition From EFI To UEFI

Mainstream 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

Key changes: EFI To UEFI

64-bit native firmware
UEFI nearly identical to EFI 1.10, but there are a few key differences
X64 required some changes to EFI specification

Runtime calls must run in same mode as 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

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

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

Windows Firmware Requirements

Simplifying 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

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

Firmware Support Roadmap Reference

Windows Release
Windows Server 2003 Service Pack 1

Architecture
x86 x64 IA-64 x86 x64 x86 x64 IA-64

Boot Firmware BIOS

Required Required Unsupported Required Required Required Unsupported Required

Runtime Firmware ACPI

Yes, logo Required Required Required Required Required Required Required Required Required

EFI
Unsupported Unsupported Required Unsupported Unsupported Unsupported Required Unsupported

EFI
Unsupported Unsupported Required Unsupported Unsupported Unsupported Supported Required Unsupported Supported

Windows Vista Windows Server Longhorn

Either BIOS or EFI

Subsequent Windows Client Releases

x86 x64

Either BIOS or EFI

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

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

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

Windows Vista And Firmware

Building 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

Windows Vista And Firmware

Building 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

A Look At The Internals

Pre-Boot Usage Model

Component 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

Pre-Boot Usage Model

Windows 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

Pre-boot Configuration
Boot 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

Pre-Boot Configuration
BCD system store
Each machine has a BCD store designated as the system BCD store
Present on the active system partition on BIOS systems Present on ESP on UEFI systems

System store is created and initialized by the setup process

Pre-Boot User Experience

Avoiding end user confusion
Transition to UEFI firmware should not be jarring to end users Differences between UEFI and BIOS environments are 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

Pre-Boot User Experience

Windows 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 presented to end user

OS Loader can run in < 2 seconds so user wont notice

If an error occurs on previous boot, user presented with localized troubleshooting UI

Pre-Boot User Experience

Multi-boot experience
If multiple Windows OSs installed, Windows boot manager is presented to user
Windows boot manager runs in users preferred locale Locale may not be the same as the UEFI boot manager

Localization support depends upon firmware graphics support

Pre-Boot User Experience

Rich 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

UEFI Installation
To install via UEFI requires that the installation be 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 options for 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

Deployment Guidelines
CD/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

Deployment Guidelines
Identifying 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

Deployment Guidelines
Consider 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 wont even notice The BCD tools abstract away any need to access the system partition

Deployment Guidelines
Consider 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

Deployment Guidelines
System 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

Deployment Guidelines
BCD 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

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

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

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

Backup

EFI Firmware
Great 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

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

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

 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.