Transcript 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
Windows Release
Windows Server 2003 Service
Pack 1
Windows Vista
Windows Server Longhorn
Subsequent Windows Client
Releases
Architecture
Boot Firmware
Runtime Firmware
BIOS
EFI
ACPI
EFI
x86
Required
Unsupported
Yes, logo
Unsupported
x64
Required
Unsupported
Required
Unsupported
IA-64
Unsupported
Required
Required
Required
x86
Required
Unsupported
Required
Unsupported
x64
Required
Unsupported
Required
Unsupported
x86
Required
Unsupported
Required
Unsupported
x64
Either BIOS or EFI
Required
Supported
IA-64
Unsupported
Required
Required
Required
x86
Required
Unsupported
Required
Unsupported
x64
Either BIOS or EFI
Required
Supported
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 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:
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.