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



Yüklə 478 b.
tarix14.10.2017
ölçüsü478 b.
#4559


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

  • 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
    • 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

  • 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



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








Yüklə 478 b.

Dostları ilə paylaş:




Verilənlər bazası müəlliflik hüququ ilə müdafiə olunur ©genderi.org 2022
rəhbərliyinə müraciət

    Ana səhifə