Inside The Windows Pre-Boot Environment Andrew Ritz Development Manager Core Platform Architecture Team Microsoft Corporation

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

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 won’t notice

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

Pre-Boot User Experience Multi-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

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 won’t 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:

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