1 / 38

System Design for the Modern PC

SYS-005T. System Design for the Modern PC. Tony Mangefeste Senior Program Manager. 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

katarina
Download Presentation

System Design for the Modern PC

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. SYS-005T System Design for the Modern PC Tony Mangefeste Senior Program Manager

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

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

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

  6. Norl Wu Senior Engineer

  7. Agenda • UEFI Firmware Debugging solution • Secure Firmware solution • Key provisioning & signing server • UEFI Manufacturing processes

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

  9. 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 …

  10. 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?

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

  12. 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 …

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

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

  16. 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 Aptio Secure Flash Update(AFSU)

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

  18. UEFI defined Capsule format: NIST SP 800-147 compliant Capsule (“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

  19. Secure Flash Update (1) FW Sets mailbox event FW verifies Capsule Image Flash App sends preferred Flash update method to FW API Abort flash process if new image fails verification checks Flash App Issues Reboot Flash Appqueries FW API

  20. PowerOn/Reset Launch PEI Secure Flash Update (2) Reset WithNew Image DONE! Flash New Image Launch DXE From Trusted New Image Locate NewFlash Image Verify NewFlash Image Abort flash process if image fails authentication

  21. AMI Remote Signing Server

  22. AMI Remote Signing Server(2)

  23. 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 FW Reset Scenario

  24. Initial FW factory default state provisioning Install default Secure Variables into the NVRAM Update KEK, db(x) certificate databases from Shell environment Use UEFI Shell or Windows 8 Powershell Provisioning tools User initiated from Aptio Setup screen (shown in today's demo) Provisioning Keys into FW

  25. 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 (2)

  26. 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 (3)

  27. Provisioning Keys (4)

  28. Provisioning Keys (5)

  29. 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? UEFI Certificate Authority(CA)

  30. Move Away from DOS-based testing: Hardware testing in DOS is limited by 16-bit design Harder to implement network access in DOS AMIDiag for UEFI Full testing without installing an OS!

  31. 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 Usage Scenarios

  32. 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 AMIDiag for UEFI: Key Features

  33. 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 Benefits of UEFI Testing AMIDiag for UEFI is designed to run in the “UEFI Boot Services” environment – the same environment used by the EFI Shell

  34. Closing Remarks

  35. 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 provisioning

  36. Thank You! For questions, please visit me in the Speakers Connection area following this session.

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

More Related