tony mangefeste senior program manager sys-005t why uefi? ux value prop from day one: fast boot, oem...
TRANSCRIPT
3
Why UEFI?• UX value prop from Day one: Fast Boot, OEM Certification,
smooth transitions, etc.• Secure Boot • eDrive support for BitLocker • SOC support • WDS Multicast• Boot Next support • Seamless Boot • Network unlock support for BitLocker• Support for > 2.2 TB system disks
Windows 8 Boot Flow
• Windows 8 installs UEFI OS Loader if UEFI is detected
• Most PCs today boot through CSM path
• For compatibility the CSM boot path available
4
5
Optimizing for UEFI
• Redesign legacy Option ROMs into UEFI Option ROMs• IHVs – deploy UEFI option ROM support,
manufacturing tools and device drivers with UEFI support
• ODMs – provide service with updated toolsets, 64-bit environments, native factory tools with UEFI
• OEMs – secure your firmware, optimize for speed• Consumer – look for newer UEFI based platform
firmware
Microsoft Recommendations to Manufacturing• Migrate tools to WinPE from DOS• Secure your Pkpriv (Platform Key private key)• Public portion OK to distribute in firmware• Only public keys go into firmware• Determine best strategy for your needs
• Standardize on a common set of tools• Long term reduction of costs
Agenda
• UEFI Firmware Debugging solution• Secure Firmware solution• Key provisioning & signing server• UEFI Manufacturing processes
Debugging
• Some drivers try directly access hardware for debug output (USB, COM, Port 80)
• Problem: • hardware is already in use
• Result: • the driver breaks system output
• Solution: • call standard output protocols• gST->StdErr• More flexible• Works with new tools
AMI has seen every type of BIOS debug problem …• Viewing POST checkpoints …• Storing POST checkpoints for analysis …• Viewing UEFI debug strings …• Measuring and improving boot time …• Source-level debug without an ITP …• Debugging firmware and UEFI applications …• Avoiding proprietary connectors …• Making debugging simple …
AMI has the remedy for these debugging problems …
Developer & Users:Common Ground• Field diagnostics & firmware development have a
common set of problems to solve …• Additional Hardware Cost• Proprietary connectors are an added hardware cost,
compared to using an industry standard port• Limited Accessibility• Can tools be connected without opening the case?
• Scaling Across Segments• Can the same tools be used in all markets?• Desktop & netbook? Embedded & server?
Three Major DebugScenarios for BIOS• Local System without Source Level Debug– POST Checkpoints & UEFI Debug Strings
• Local System with Source-Level Debug– Setup source level debug without an ITP connector– Setup source level debug without opening the case– Debug in firmware or at the UEFI Shell
• Remote System with Source Level Debug– Get help from AMI without any travel costs– Get help from AMI without shipping the system
Debugging Today’s PC …The Problem With Port 80h
• Working with “POST checkpoints” can be outdated …• Using a full-size slot?• Using a proprietary
debug slot?• Opening the case?
• Source-level debug has the same issue• Proprietary connectors
13
The Remedy …USB 2.0 Debug Port
• Uses a standard USB connector
• Uses standard EHCI debug port feature in USB 2.0
• Uses a standard port already available to the customer
• More applications than checkpoints …
Why Use USB as a Debug Solution?• Externally Accessible– Don’t have to open the case to connect the device
• USB 2.0 Enables Early Debugging– Accessible via the USB EHCI debug port
• No Additional Hardware Cost– Use the same USB port for debugging devices or with
standard USB 1.1 & USB 2.0 devices• USB is Ubiquitous– Users expect USB to be enabled
Enabling AMI Debug for UEFIin Aptio 4.x is Easy …
• Hardware– Make USB Debug Port accessible to
the user– Same configuration as used for
AMI Debug Rx• BIOS & UEFI– Add “USBRedirection” and
“Debugger” eModules– Layers on top of existing “AMI
Debug Rx” eModule• Developer– Switch AMI Debug Rx to “DEBUG”
mode and setup the host-target connection
Aptio Secure Flash Update(AFSU)Aptio Secure Flash Update Methodology• Use UEFI FW Capsule as BIOS image delivery method• Aptio Flash utility supports secured Flash update
• Aptio BIOS Image is Digitally Signed via AMI Remote Signing Server• AMI Remote Signing Server (RSS)• Signed using Simple PKI infrastructure
• Use digital signature to authenticate the image• UEFI-approved digital signature protocols• Signed using Simple PKI infrastructure • EMSA PKCS v1.15 or RSA PSS signature padding
schemas• RSA-2048 and SHA256 algorithms
Stays within UEFI Specifications• Security based on defined standards• Allows OEMs to easily develop compatible tools
Uses driver signing concepts• Allows verification of code ownership, integrity and
compatibility
Seamless integration with current Aptio cores• Secure SMIFlash eModule replaces SMIFlash eModule• Tools integrate into Aptio build process
ASFU Advantages
UEFI defined Capsule format: NIST SP 800-147 compliantCapsule (“Capsule-in-Memory”)• Capsule is put in memory by an application in the OS
• Mailbox event is set to inform BIOS of pending update
• System reboots, verifies the image and update is preformed securely by the BIOS
Recovery (“Capsule-on-Disk”)• Capsule is stored on a predefined disk
• Mailbox event is set to inform BIOS of pending update
• System reboots, loads the image from disk, verifies the image and update is preformed securely by the BIOS
ASFU Methods
Flash App
Issues Reboot
FW verifies Capsule Image
Flash Appqueries FW API
Flash App sends preferred Flash
updatemethod to FW API
Abort flash process if new image fails verification
checks
FW Sets mailbox event
Secure Flash Update (1)
PowerOn/ResetLaunch PEI
Locate NewFlash Image
Verify NewFlash Image
Abort flash process if image fails authentication
Flash New
Image
Reset WithNew
Image
DONE!
Launch DXE From
Trusted New Image
Secure Flash Update (2)
FW Reset Scenario
• Factory Reset – BIOS Initiated• Reverts Firmware to Initial Default State• PK
• KEK – MS KEKpub + OEM KEK(optional)
• “db” – at least 1 certificate: MS CA
• “dbx” – empty
• The scenario above also applies to Catastrophic firmware reset
Provisioning Keys into FW
1. Initial FW factory default state provisioning• Install default Secure Variables into the NVRAM
2. Update KEK, db(x) certificate databases from Shell environment• Use UEFI Shell or Windows 8 Powershell
Provisioning tools
3. User initiated from Aptio Setup screen (shown in today's demo)
Provisioning Keys (2)
Initial FW factory default state provisioning
• Keys are baked into Mass Production (Most Preferable)
• A flat flashmap could be created and burned with all this information already set into NVS during manufacturing
• BIOS must support Factory reset to defaults in case of recovery or forced Factory defaults
Provisioning Keys (3)
Use UEFI Shell or Windows 8 PowerShell tools
•Use UEFI Shell application, e.g. AMI’s SetVariable.efi
• Windows PowerShell: Load SecureBoot cmdlets: “Import-module secureboot” from Admin Level Powershell• Downside: Requires full Windows 8 Installation
UEFI Certificate Authority(CA)
• BIOS Firmware will hold the KEK and UEFI signatures for authenticated FW images
• UEFI signatures originate from a Certificate Authority (CA)
• Who acts as a CA for Windows 8 boot manager image and all other UEFI images?
• Who signs other OS’ (e.g. Linux) boot loaders?
AMIDiag for UEFI
Move Away from DOS-based testing:• Hardware testing in DOS is limited by 16-bit design• Harder to implement network access in DOS
Full testing without
installing an OS!
Usage Scenarios
• Run AMIDiag from a PXE server (network boot) or USB drive (local storage)• Set up batch script for burn-in
cycle (24-48 hours) or integration test (30- 60 min)• Automate batch scripts using the UEFI shell• Log “all errors” to create a full testing report
• Embed AMIDiag into the BIOS ROM,
or run from a system service partition• Run using local VGA display or console redirection (for embedded/server systems)• Users select pre-defined batch
scripts or specific system tests from the menu• Log “errors only” to quickly identify system faults
Manufacturing Line Field Diagnostics
AMIDiag for UEFI: Key Features
• Launch AMIDiag from UEFI Shell or ROM• Adds the diagnostic as a UEFI firmware volume• Aptio 4.x eModule available for easy integration• Removal of shell dependency for AMIDiag for UEFI
• Launch AMIDiag via PXE Server• Execution of diagnostic from central repository• Can be used for manufacturing environments or in-
house quality assurance testing
Benefits of UEFI Testing
This offers a number of testing advantages:• Test in processor protected mode (IA32 or x64)• Single-tasking environment for hardware testing• Access to all system memory and peripheral hardware• Pre-OS shell environment available with UNIX-style command prompt and batch scripting capabilities• Networking is available in UEFI boot services • UEFI boot and runtime services are available to the diagnostic
software
AMIDiag for UEFI is designed to run in the “UEFI Boot Services” environment – the same environment used by the EFI Shell
Call to Action
• Balance modernizing your manufacturing processes with costs
• Reuse code where possible, avoid proprietary tools• Think about debugging hardware during the
process• Identify the work involved in each stage of system
provisioningBlank board
Provisioned
Field serviced
© 2011 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.