UEFI Overview for Meetup Vincent Zimmer January 28, 2016 NOTE: These are my personal opinion and not those of my employer
Agenda •
Background on UEFI
•
EFI Basics
•
Network Deployment
•
Security
•
Other
Background on UEFI
Industry Transition Pre-2000
All Platforms BIOS were proprietary
2000
Intel invented the Extensible Firmware Interface (EFI) and provided sample implementation under free BSD terms
2004
tianocore.org, open source EFI community launched
2005
Unified EFI (UEFI) Industry forum, with 11 members, was formed to standardize EFI
2015
240 members and growing! Major MNCs shipping; UEFI platforms crossed most of IA worldwide units; Microsoft* UEFI x64 support in Server 2008, Vista* and Win7*; RedHat* and SuSEl* OS support. Mandatory for Windows 8 client. ARM 32 and 64 bit support. ACPI added.
What is UEFI? UEFI Platform Initialization Overview Human User OS (UEFI or Today’s)
Pre-boot Tools
UEFI PI Scope - Green “H”
UEFI Specification
GUI Application Libraries Drivers Network OS Firmware Hardware
Full system stack (user -> hardware)
Platform Drivers
Silicon Component Modules Hardware PEI/DXE PI Foundation Modular components
UEFI 2.5 specifies how firmware boots OS loader UEFI’s Platform Initialization (PI) 1.3 Architecture specifies how Driver Execution Environment (DXE) Drivers and Pre-EFI Initialization (PEI) Modules (PEIMs) initialize SI and the platform DXE is preferred UEFI Implementation PEIMs, UEFI and DXE drivers implement networking, Update, other security features
What’s in UEFI
UEFI [Compliant] Firmware CPU Reset SEC
S-CRTM; Init caches/MTRRs; Cache-as-RAM (NEM); Recovery; TPM Init Pre-EFI Init (PEI)
S-CRTM: Measure DXE/BDS Early CPU/PCH Init Memory (DIMMs, DRAM) Init
Driver Exec Env (DXE)
ACPI, UEFI SystemTable, SMBIOS table, Lock resources
UEFI “Core” functionality, Continue initialization of platform & devices Enum FV, dispatch drivers (network, I/O, service..), Produce Boot and Runtime Services, SMM Initialization Boot Dev Select (BDS)
ExitBootServices. Minimal UEFI services (Variable, Capsule)
Boot Manager (Select Boot Device) EFI Shell/Apps; OS Boot Loader(s); Option ROM Runtime / OS
Implementation
Specifications
Specification & Tianocore.org Timeline http://uefi.org UEFI 2.0
UEFI 2.1
UEFI 2.2
UEFI 2.3
UEFI 2.3.1 UEFI 2.5
PI 1.0
PI 1.1
PI 1.2 Shell 2.0
PI 1.4
Packaging 1.0
ACPI6.0
2006
2007
2008
SCT UEFI 2.0
EDK 1.01: UEFI 2.0
2009
2010
SCT UEFI 2.1
SCT UEFI 2.3
EDK 1.04: UEFI 2.1
EDK 1.06: UEFI 2.1+
PI 1.0
PI 1.0
SCT PI 1.0
EDK II*: UEFI 2.1+
UDK2010: UEFI 2.3
PI 1.0
PI 1.2
http://tianocore.org SourceForge.net All products, dates, and programs are based on current expectations and subject to change without notice.
Intel Confidential
2011-15
FSP 1.0/1.1 UDK2014 UEFI 2.4 PI 1.3
•
USWG • UEFI Specification Working Group • PIWG www.uefi.org • Platform Initialization Working Group • ASWG • ACPI Specification Working Group ASWG, PIWG • BOD • Board Of Directors • USST BOD • USWG Security Sub-team USRT • Chaired by Vincent Zimmer (Intel) USWG • Responsible for all security related material and the team that has added security infrastructure in the UEFI spec UNST • USRT • UEFI Security Response Team USST • Chaired by Dick Wilkins (Phoenix) • Provide response to security issues. …… • UNST • UEFI Network Sub-team (VZ chairs, too) Note: Engaged in firmware/boot • Evolve network boot & network security Related WG’s of Trusted Computing Group (TCG), IETF, DMTF infrastructure for UEFI Specification
Working Groups in UEFI
UDK2015 Available on Tianocore.org UEFI Development Kit 2014 (UDK2014)
How to build it? UDK2015 Industry Standards Compliance • UEFI 2.0, UEFI 2.1, UEFI 2.2, UEFI 2.3, UEFI 2.4; PI 1.0, PI 1.1, PI 1.2, PI1.3, ACPI 5.1
Extensible Foundation for Advanced Capabilities
Support for UEFI Packages • Import/export modules source/binaries to many build systems
Maximize Re-use of Source Code** • Platform Configuration Database (PCD) provides “knobs” for binaries • ECP provides for reuse of EDK1117 (EDK I) modules • Improved modularity, library classes and instances • Optimize for size or speed
Multiple Development Environments and Tool Chains** • Windows, Linux, OSX • VS2003, VS2005, WinDDK, Intel, GCC
Fast and Flexible Build Infrastructure** • 4X+ Build Performance Improvement (vs EDKI) • Targeted Module Build Flexibility
Maximize the open source at www.tianocore.org Intel® UEFI Development Kit 2010 (Intel® UDK2010)
** benefit of EDK II codebase
• Pre-OS Security • Rich Networking • Manageability
EFI Basics
EFI Specification Architectural abstraction for OS and firmware scope: platform boot to OS loader handoff
Features in common with other boot specs coherent, scalable platform environment abstracts OS from platform firmware definition
reasonable device abstraction free of “bios” interfaces architecturally sharable system partition outside OS
Plus some additional benefits...
Unique EFI Value Simplifies OS independent platform value-add spec is extensible interface, not implementation de-couple OS and firmware development leaves room for platform innovation and differentiation
Evolution not revolution layer on existing firmware code enables longer term migration away from legacy
Compatibility preserved EFI systems can boot existing OS and EFI-aware OS
boot through current native OS partitions
Builds on existing OS and firmware investment complements existing specs: ACPI, SMBIOS, ...
EFI Design Overview Reuses current table-based interfaces IBI File System Structure (ok, we used FAT) architecturally defined system partition embeddable in OS partitions supports “IBI OS Loaders” and “IBI Drivers”, …
Runtime Services Boot Services abstracts access to devices through handles & protocols protocols enable extensible object-style services
What is EFI?
Operational Model EFI Driver
OS Booted
EFI Application
EFI Boot code Retry
Platform Init Standard firmware platform initialization
EFI Image Load Drivers and applications loaded iteratively
Failure
EFI OS Loader Load Boot from ordered list of EFI OS loaders
OS Loader
EFI API Boot Services Terminate
Operation handed off to OS loader
API specified by EFI Specification Underlying implementation of EFI
EFI services consumer code
EFI Spec covers API definition only
EFI Services
Boot Services Events and notifications Polled devices, no interrupts
Watchdog timer Elegant recovery
Memory allocation Handle location – for finding protocols Image loading Drivers, applications, OS loader
Complete and size efficient
EFI Services
Event, Timer and Task Services No interrupts in EFI. Only 1 interrupt exists for the global scheduler Software cooperative with different task priority levels (TPL) TPL_Application: normal level TPL_Callback: priority level for most notify function TPL_Notify: priority level where I/O is performed
TPL_High: timer interrupt context
EFI Services
Runtime Services Services available at both boot time and runtime Timer, Wakeup alarm Allows system to wake up or power on at a set time.
Variables Boot manager handshake
System reset
Minimal set to meet OSV needs
Intel® UDK2015 Putting it All together Intel UDK2014 Packages
Silicon Packages
UEFI 2.2, 2.3, PI 1.1, 1.2
ECP
Security
Network/IScsi
Mde
UEFI 2.3 and PI1.2 definitions UEFI2.3/PI 1.2 Tool updates
• Platform, chipset & CPU
Backward compatible solution for PI 1.1 SMM/S3/SMBIOS
IP4 stack update for IP6-readiness IP6 stack, ISCSI, PXE, Ipsec, VLAN Configuration Tools
• • •
Platform ROM Image
User identification Authenticated Variable Driver Signing
Compatibility package
Shell
• Build system UEFI Shell 2.0
Advanced Development Environment Modular. Flexible. Extensible. Intel® UEFI Development Kit 2010 (Intel® UDK2014)
UEFI Features – Configuration Infrastructure
Review of IHV Applicable UEFI Features
Rudimentary Mock-up of Interfaces
Pre-O/S
Runtime
Review of IHV Applicable UEFI Features
UEFI Features – Driver Health * Initial State ** Terminal State
Healthy *, **
Driver Health Protocol Configuration Required *
Repair Required *
Reconnect Required **
Failed *, **
Driver Health Protocol GetHealthStatus()
BIOS
Reboot Required **
Repair()
Add-in Device Supported() Start() Stop()
1) 2)
3)
UEFI BIOS attempts to initialize a device with an option ROM a) Device runs into an issue which might be recoverable UEFI BIOS checks on the health of the device a) Device may return some forms-based data references to the BIOS so it can optionally communicate with the user. It also returns status regarding the health (see state diagram in upper right). UEFI BIOS can optionally interact with the user to notify them of the message the device wanted to communicate, and if the driver health indicated that repair was required, the BIOS can automatically call the option ROM’s repair facility.
Option ROM can advertise health status
UEFI Benefits to IHVs
UEFI Benefits to IHV – Remove some burdens Do not need to carry their own UI infrastructure Less code/logic to support By centralizing any key polling delays, speeds up platform booting.
Option ROM
1) 2)
3)
Display Text/Logo Poll for keystrokes (delaying boot) a) Present UI infrastructure b) Handle UI responses Initialize Hardware
Option ROM
1) 2)
Register Content with platform When called, initialize Hardware
Minimize IHV burden with UEFI
UEFI Benefits to IHVs
UEFI Benefits to IHV – Expand Configurability EBC (EFI Byte Code) allows a single image option ROM to operate on multiple CPU environments Maximal compatibility while minimizing binary size impact
Option ROM
Binary Image for CPU type x Binary Image for CPU type y Binary Image for CPU type z
Option ROM
EBC Image for all CPU types running on UEFI
UEFI Benefits to IHVs
UEFI Benefits to IHV – Expand Configurability No longer a black-box Can describe their payload and interact with platform in standard fashions Expose content so that it can seamlessly be integrated in platform solutions. Seamlessly integrate device data into the platform’s configuration menu
Configure device(s) remotely Room 1
Room 2
Connected Forms Browser/Processor
UEFI expands configurability of devices
Network deployment
PXE Boot Challenges Preboot eXecution Environment Security Issues Only physical. No encryption or authentication. Rouge DHCP servers, man-in-the-middle attacks Scaling issues Circa 1998 TFTP timeouts / UDP packet loss Download time = deployment time = $$$ Aggravated in density-optimized data centers OEMs and users workarounds Chain-load 3rd party boot loaders (iPXE, mini-OS)
PXE is not keeping up with modern data center requirements
Network Stack In UEFI v2.4 IPv4 PXE Ping
iSCSI4 iSCSI6
IPv6 PXE
Ping6 IfConfig6
IfConfig
DHCP4
MTFTP4
FTP4
IP4Config TCP4 UDP4 ARP IP4 VLAN VLANConfig
MTFTP6
IPSec
MNP SNP UNDI / NII www.uefi.org
DHCP6
TCP6 UDP6 IP6 IP6Config EAP
Network Stack In UEFI v2.5 Builds on top of UEFI 2.4 DNS (IPv4 / IPv6) HTTP (IPv4 / IPv6)
TLS (for HTTPs) HTTP Boot Wire Protocol Bluetooth® technology
Wi-Fi*
29
UEFI Native HTTP Boot HTTP Boot Wire Protocol
Addresses PXE issues
• Boot from a URL • HTTPs addresses security • Target can be: • TCP reliability 1. EFI Network Boot Program (NBP) • HTTP load balancing 2. Shrink-wrapped ISO image • URL pre-configured or auto-discovered (DHCP)
HTTP Boot DHCP Discovery HTTP Boot DHCP Discovery New HTTP Boot “Architectural Types” to distinguish from PXE Client sends DHCP Discover request DHCP Server responds with offer that includes the boot file URL Clients resolves URL server name from DNS Client downloads boot image from HTTP server using HTTP(s)
RAM Disk Standard UEFI 2.5 defined RAM Disk device path nodes - Standard access to a RAM Disk in UEFI - Supports Virtual Disk and Virtual CD (ISO image) in persistent or volatile memory
ACPI 6.0 NVDIMM Firmware Interface Table (NFIT) - Describe the RAM Disks to the OS - Runtime access of the ISO boot image in memory
HTTP Boot is the emerging solution for modern data centers.
Security Features
Usage of the EDK II Security Ingredients System
Protect
Firmware
Detect
Protect Detect Recover
Security Solutions •
Signed capsule updates
•
UEFI Secure boot •
•
local / network
TPM on the platform •
Measured boot
•
Root of Trust for Reporting
•
Storage
•
Protect machine configuration & UEFI Secure boot trust anchors
•
In-band and out-of-band network security
• HTTP boot for data center
Protect
Solving Firmware Update • Reliable update story • •
Fault tolerant Scalable & repeatable
• How can UEFI Help? • • •
Capsule model for binary delivery Bus / Device Enumeration Managing updates via • • •
EFI System Resource Table Firmware Management Protocol Capsule Signing
Recover
UEFI Secure Boot vs. TCG Trusted Boot
Check signature of before loading
• UEFI will require remediation mechanisms if boot fails
UEFI PI will measure OS loader & UEFI drivers into TPM (1.2 or 2.0) PCR (Platform Configuration Register)
UEFI Firmware UEFI OS Ldr, Drivers
Kernel Drivers
• UEFI Secure boot will stop platform boot if signature not valid (OEM to provide remediation capability)
Detect
record in PCR
UEFI authenticate OS loader (pub key and policy)
Protect
TPM
Apps • TCG Trusted boot will never fail • Incumbent upon other software to make security decision using attestation
UDK2015 SecurityPkg
Protect
RandomNumberGenerator • UEFI driver implementing the EFI_RNG_PROTOCOL from the UEFI2.4 specification
Trusted Computing Group (TCG) • PEI Modules & DXE drivers implementing Trusted Computing Group measured boot • EFI_TCG_PROTOCOL and EFI_TREE_PROTOCOL from the TCG and Microsoft * MSDN websites, respectively
UserIdentification • DXE drivers that support multi-factor user authentication • Chapter 31 of the UEFI 2.4 specification
Library • DxeVerificationLib for “UEFI Secure Boot”, chapter 27.2 of the UEFI 2.4 specification + other support libs
VariableAuthenticated • SMM and runtime DXE authenticated variable driver, chapter 7 of the UEFI2.4 specification https://svn.code.sf.net/p/edk2/code/trunk/edk2/SecurityPkg
Detect
Additional Capabilities in Open Source Protect
Variable Lock Protocol
Recover
Make variables read-only https://github.com/tianocore/edk2/blob/master/MdeModulePkg/Include/Protocol/VariableLock.h
Lock Box Protect content across re-starts https://github.com/tianocore/edk2-MdeModulePkg/blob/master/Include/Protocol/LockBox.h
Capsule Update Generic capsule update driver support http://comments.gmane.org/gmane.comp.bios.tianocore.devel/8402 https://svn.code.sf.net/p/edk2/code/trunk/edk2/MdeModulePkg/Universal/EsrtDxe https://svn.code.sf.net/p/edk2/code/trunk/edk2/MdeModulePkg/Universal/CapsulePei
HTTP boot https://svn.code.sf.net/p/edk2/code/trunk/edk2/MdePkg/Include/Protocol/Http.h Recovery Device support for recovery from PEI https://svn.code.sf.net/p/edk2/code/trunk/edk2/MdeModulePkg/Include/Guid/RecoveryDevice.h
Roots of Trust
Protect Detect Recover
•
A root of trust (RoT) can be static (S) in OEM macrocode firmware, dynamic (D) in Intel code post-recent, and/or hardware (H) based
•
Root of Trust for Verification (RTV) – •
HRTV – Boot Guard, other
•
SRTV – UEFI Secure Boot, Chromebook Verified Boot
•
Root of Trust for Update (RTU) •
•
UEFI Capsule Update, FOTA
Root of Trust for Measurement (RTM) •
SRTM – EFI Measured boot, DRTM – TXT SENTER
•
HRTM – Server TXT Startup ACM
•
Root of Trust for Storage (RTS) - TPM storage root key, etc
•
Root of Trust for Reporting (RTR) – TPM PCR
Trusted Boot
Protect Detect Recover
•
Ensure the correct software stack is executing •
Code verification (RTV)
•
Protected update (RTU)
•
Report the state of the booted environment •
Attestation (RTM, RTR)
•
Boot remediation environment in case of main loader failure (RTV) or update components in case of errant local firmware (RTU)
•
For Intel platforms, many implementations of HRTV. UEFI Secure Boot (SRTV) required on all Windows clients since 2012 (Window8). Windows10+1 year will require TPM on all platforms (RTR, RTM, RTS). Chromebooks use TPM + Verified Boot (RTV).
Full Verified Boot Sequence
CPU/SO C (Intel)
Start Block PEI Measure
Intel Boot Guard
(OEM)
BIOS DXE/UEFI (OEM)
Measure
Detect
OS Loader/Kernel Measure
(OSV)
Executable
Executable
Executable
Protect
Measure TXT launcher (e.g. TBOOT)
MLE
Enforces
Enforces
Policy Engine
Policy Engine
Policy Engine
Policy Engine
Policy
Policy
Policy
Policy
Enforces
Intel® Device Protection Technology with Boot Guard http://www.intel.com/content/dam/www/public/us/e n/documents/product-briefs/4th-gen-core-familymobile-brief.pdf
Enforces
OEM PI Verification Using PI Signed Firmware Volumes Vol 3, section 3.2.1.1 of PI 1.3 Specification
OEM UEFI 2.5 Secure Boot Chapter 30.2 of The UEFI 2.5 Specification
TXT w/ LCP Industry std TCG DRTM API And/or the Intel MLE arch
SMM
Full System Picture – UEFI PI boot and runtime
Protect Detect Recover
RING 3 RING 0
BIOS
RING 0
RING 0
SMM
RING 3
Kernel Kernel Kernel Drivers HAL Drivers HAL Drivers HAL
RING 3
Trusted (e.g.SMM, TZ) domain
Application Application Application Application Application Application Application Application Application Application Application Application Application Application Application
Non SMM domain
Protect & Recover the UEFI PI implementation UEFI Capsule Update Hardware Secure Boot using Intel® Boot Guard on non-open platforms
Trusted Trusted Container Other Container Guests
Monitor
RING 0p
Hypervisor / OS UEFI PI BS & RT HW
HW
HW
Detect if the Hypervisor and OS is expected one UEFI Secure Boot (and TXT+LCP on non-open platforms) EFI TCG Measured boot
Protect at runtime
HW TPM
SMM Transfer Monitor (STM) to protect platform, hypervisor, and operating system (OS) from the BIOS SMM Intel® Virtualization Technology (Intel® VT) Intel® Trusted Execution Technology (Intel® TXT)
BIOS Attack Surfaces
CanSecWest 2015 Vancouver, Canada UEFI, Open Platforms, and the Defender’s Dilemma
•
Attacking Hypervisors Using Firmware and Hardware Bulygin, Matrosov, Gorobets, & Bazhaniuk
Unsafe Coding Practices
Server Mgmnt Interfaces
BIOS Update Interfaces
Shell Apps & Diags
Vincent Zimmer @vincentzimmer, vincent.zimmer @intel.com | @gmail.com
Option ROMs
Standard APIs
BIOS
BIOS Vendor Hooks
System Mgmnt Mode
More defense in depth • In process w/ next release - NX to avoid execution outside of SMRAM
- Non-executable stack - Make the data area instead of SMRAM non-executable
• Under review for SMM and normal boot service execution - Randomize portions of SMRAM data structures - ALSR - Non-executable stack - Stack canaries
Futures
SMM Flow with STM
• firmware.intel.com to find STM user guide • STM Reference implementation built on EDKII infrastructure
- Build system, Mde Libraries, test driver and MinnowMax integration
Servers and UEFI PI Firmware UEFI Secure boot has been a client Windows requirement since Windows8. All Linux distributions have upstream UEFI Secure boot support
Static measured boot being added to Grub and Linux boot path SMM flaws are a client and server concern TLS being built for HTTP boot to allow for REST/Redfish in-band management flows and HTTP-S data center booting
References 1.
UEFI Forum http://www.uefi.org
2.
EFI Developer Kit II http://www.tianocore.org
3.
White papers, training, projects http://firmware.intel.com
4.
CHIPSEC: https://github.com/chipsec/chipsec
5.
Trianocore security advisories
6.
UEFI Forum USRT (
[email protected] , PGP key)
7.
Intel PSIRT (
[email protected], PGP key)
8.
Books http://www.apress.com/apressopen UEFI SHELL
9.
UEFI Overview UEFI Intel Technology Journal
10.
Platform Security information: https://firmware.intel.com/blog/
11.
EDK II Security Fixes: http://www.tianocore.or/security
12.
SMM attacks from https://cansecwest.com/agenda.html “Corey Kallenberg & Xeno Kovah, LegbaCore - How many million BIOSes would you like to infect?”, “Rafal Wojtczuk & Corey Kallenberg - Attacks on UEFI Security”, “John Loucaides & Andrew Furtak, Intel - A new class of vulnerability in SMI Handlers of BIOS/UEFI Firmware”
13.
STM Specification and code: https://firmware.intel.com/content/smi-transfer-monitor-stm
14.
Alternate RTV on uServer http://www.intel.com/cd/edesign/library/asmo-na/eng/558768.htm
Questions?
Backup
Contents Time USB1.1
USB 2
Since ~2001
PCI
PCIe
ACPI 2 UEFI 2.0
USB 3
ACPI 3 UEFI 2.1
ACPI 4
UEFI 2.2
PI 1.0
UEFI 2.3
PI 1.1
EDK I
ACPI 5.1 UEFI 2.4 PI 1.2
ECP Hundreds deep Today Sustaining
53
New dev
Core evolution 1.4 1.1
1.3
1.2
3.1 Trunk 1.0
2.0
3.0 2.1
3.2
3.3
4.0 2.2
2.3
Time
Different branches to support
54
The road from core to platform tianocore.org Open Source Reference Tree OEM BIOS New product Existing product
End users updating?
Commercial product in the field Consumer product in the field
IBV
All Intel OEM IBV ODM
ODMs updating?
ODM BIOS Existing ODM product
Time
New product
UEFI Driver Signing Why? – Origin & Integrity
How? – Authenticode PE
PKCS#7 + Authenticode Ext
PE Image ContentInfo PE Header
PE file hash
Certificate Directory
Certificate Section 1
……
X.509 Certificate
Section N Type Attribute Certificate Table
SignInfo Signed hash of ContentInfo
UEFI Authenticated Variable
Why? – Integrity (no confidentiality) How? – Time Based Authenticated Variable
Input Variable Data Authentication Time Stamp
ContentInfo PKCS#7 N/A
Certificate X.509 Certificate
Type Certificate
Data Content
SignInfo Signed hash of VariableName + VariableGuid+ Attributes + TimeStamp + DataContent
Put them altogether: UEFI Secure Boot
Guarding & Verifying in Pre-boot •
PI & UEFI complement each other to impart platform security through guarding and verification during preboot.
•
PI facilitates platform hardening by guarding internal firmware ingredients that consume reset vector, initialization of CPU, Memory, Chipset etc.
•
UEFI signing allows robust platform scaling through verified inclusion of external firmware ingredients such as OPROMS into the trust chain
Load the UEFI image as long as it is trusted
Linux Update – Multiple OS Boot with MOK
Either the UEFI CA key or SUSE key will let the shim boot with UEFI secure boot
Multi-Signature Support for Shim
Rollbacks with fences Version 1
Version 1
Version 1
Version 2
Version 2
Version 2
Version 3
Version 3
Version 3 “Fence”
Each version fixes some issues with the previous. Since none are known to have security flaws, each new version allows updates to all older versions.
Version 4 In V4, one of the issues fixed in V3 is realized to be a security fix. V4 will not allow updates to earlier versions, even V3 since it allows update to V2.
Version 4
Version 5
Version 5 can now accept only versions 5 and 4.
Code Management Analyze and Mark external Interfaces where input can be attacker controlled data, comment headers /**
Install child handles if the Handle supports GPT partition structure. Caution: This function may receive untrusted input. The GPT partition table is external input, so this routine will do basic validation for GPT partition table before install child handle for each GPT partition.
@param[in] @param[in] @param[in]
This Calling context. Handle Parent Handle. DevicePath Parent Device Path.
**/ EFI_STATUS PartitionInstallGptChildHandle
UDK2010 example: http://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2/MdeModulePkg/Universal/Disk/PartitionDxe/Gpt.c
Intel® Virtualization Technology (Intel® VT) VMEXIT Conditions CR0, CR4 accesses (basic CPU operations) CR3 writes (address space changes) CR3 reads, INVLPG (paging) MSR & debug register accesses I/O instructions (per-port bitmap) CPUID, INVD Exceptions
Virtual Machines
0P
OS
VMM
GDT
GDT
IDT
IDT
Virtual Machine Monitor
VMCS
VMEnter
0D
Applications
VMExit Events
3
VM Control Structure (VMCS) Which operations cause VMEXITs Which states change on VMEXITs and VMENTER VMM state area (state loaded on VMEXITs) Guest state area (saved on VMEXIT, restored on VMENTER)
BIOS STM Opt-in • BIOS should vigorously defend SMRAM - …because of it’s power, and critical importance to platform function - Therefore, BIOS must not enable an arbitrary or unknown STM
• BIOS populates MSEG with an STM image - BIOS should enforce it’s own policy regarding what is an “acceptable” STM Likely policy: – STM image supplied as part of BIOS flash image – BIOS flash image has controlled updates (e.g. signed) – Therefore: “I found it in my flash, so it’s acceptable”
Many other BIOS policy options are possible
• IA32_SMM_MONITOR_CTL.[0]
/* Valid bit */
- BIOS sets to 1 if STM is present, BIOS clears to 0 (default) if no STM is present - Must be programmed identically across all CPU threads, Register only writable from SMM
• STM is idle and quiescent until it is “configured” - SMI is handled via legacy SMI mechanism
Beyond STM Isolation, Moving to Testing
Usenix* WOOT 2015: KLEE->S2E->….
WOOT 2015 Paper
System Management Mode (SMM)
SMM
• SMM is the most privileged software in the system • It has access to all host accessible resources - Memory, TPM, chipset registers, device registers - It can be used to protect flash – which contains UEFI code and variables
• It is not affected by typical OS/VMM level software controls - Protection rings, paging, VMX… - System Management Interrupt (SMI) can’t be masked - SMRAM can’t be inspected & is transparent to typical system software
• It is commonly critical for proper system operation • Mitigations - code review, validate internal/external input, no call outs
System Management Mode with UEFI PI
• Orange regions are SMRAM • Software model defined in PI 1.4 specification, volume 4 • Implementation at edk2\MdeModulePkg\Core\PiSmmCore
Protect
Application
Application
Application
Application
HAL
STM creates SMM state save area for BIOS Other VMs
- Scrubs register state if protected code has been interrupted by SMI
STM resumes BIOS SMI handler in guest VM
BIOS SMM code handles SMI
RSM
VMRESUME
Drivers
RING 0
Kernel
SMM
SMI occurs - control is transferred to STM (VMEXIT) RING 3
BIOS
SMRAM
Application
Virtualization of BIOS SMI Handler
STM traps on protected hardware accesses - Based on negotiated protection profile
STM
SMI VMRESUME
Hypervisor
BIOS SMM executes RSM (VMEXIT) to STM STM restores interrupted VMs and resumes them
PEI FV
1. Enroll Authenticated Variables PK KEK
3. Post ship update DB
2B. Signature Verification
2C. Signed Image Load & Measure to TPM
db
Certificate
dbx
Certificate
OpRom.efi Certificate + SignInfo
2A. Signed Image Discover
Variable
OsLoader.efi
DXE FV
Certificate + SignInfo
Image Verify
UEFI Secure Boot CeremonyEllison, Carl M. “Ceremony Design and Analysis,” IACR Cryptology ePrint Archive (2007): 399. https://eprint.iacr.org/2007/399.pdf
UEFI Interfaces Boundary for PM_AUTH/ EndOfDxe Event
Startup PEI Core CPU Init
UEFI Shell
Device, Bus, or Service Driver
Chipset Init Board Init
EFI Driver Dispatcher
Transient OS Boot Loader
Power on
Driver Execution Environment (DXE)
Boot Dev Select (BDS)
[ . . Platform initialization . . ] OEM/PM extensible
OS-Present App
Boot Manager
Architectural Protocols
Security Pre EFI (SEC) Initialization (PEI)
OS-Absent App
Final OS Boot Loader
Final OS Environment
Transient System Load
Run Time
(TSL)
(RT)
[ . . . . OS boot . . . . ] 3rd party extensible
Overall UEFI Boot Timeline
Shutdown
Delivering Firmware Binaries
Protect Recover
• UEFI supports Capsule format • •
Tools for capsule generation Core logic for capsule handling
• Extensible Capsule format • • •
Self-contained Discrete updates Composite updates
• Firmware Management Protocol allows • •
Reading / updating firmware Integrity checks
Background • Problem statement Making UEFI-based www.uefi.org server firmware easier to use with hyper scale deployments, including complementing efforts like the Open Compute Project (OCP) http://www.opencompute.org/ •
2 approaches Leverage and evolve specifications in the UEFI Forum – UEFI Main Spec, ACPI, PI, and Shell to solve deployment and management issues – firmware update, network provisioning, diagnostics OCP_PREZO OCP_WP
•
• •
•
Created a work registry for UEFI Forum and OCP collaboration Enhancement the hardware management working group to include UEFI capabilities into OCP
Enhance the open source community on www.tianocore.org to go from having just an open source core and high-level interface code to include a full platform solution •
Today’s discussion
Idea - Intel-based Open Source Platform for UEFI Start with EDKII core – existing upstream/open source core on tianocore.org that implements ACPI, UEFI, PI from www.uefi.org Finish with simplified, product quality, open source platform package (MinPlatPkg) . Built on industry standards and EDK II technology for ease of porting. Upstream platform code to tianocore.org Add the Intel ® Firmware Support Package (FSP) for small amount of closed source SI init (DDR, links) – Intel.com/fsp
OS UEFI Specification
Open Source Platform Pkgs Open Source EDK II core Silicon ® Component Modules
PEIMs Intel FSP Hardware/Silicon
