Tony MangefesteSenior Program Manager

System Design for the Modern PC

SYS-005T

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

Norl WuSenior Engineer

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)

AMI Remote Signing Server

AMI Remote Signing Server(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

Provisioning Keys (4)

Provisioning Keys (5)

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

Closing Remarks

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

Thank You!

For questions, please visit me in the Speakers Connection area following this session.

© 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.