Firmware Storage : Technical Overview Copyright © 2006-2008 Intel Corporation Intel Corporation...

Firmware Storage : Technical Overview

Copyright © 2006-2008 Intel Corporation

Intel CorporationSoftware and Services Group

® UEFI / Framework Training 2008UEFI / Framework Training 2008UEFI / Framework Training 2008UEFI / Framework Training 2008Copyright © 2006-2008 Intel Corporation

•Other trademarks and brands are the property of their respective owners Slide 2

Firmware Storage• Platform Initialization Firmware Volume

– Basic storage repository for data and code is the FV – Each FV is organized into a file system, each with attributes

• Firmware File System format– A firmware file system (FFS) describes the organization of files

and free space within the firmware volume. – Each firmware file system has a unique GUID, which is used by

the firmware to associate a driver with a newly exposed FV

• Firmware Files– Code and data stored in firmware volumes– Each of the files has the following attributes

• Name, Type, Alignment, Size

See § 2.1 PI 1.1 Vol. 3 Spec



Code/Data Storage Models• File System Support for EFI system partition

– File system header contains a GUID which describes the format of the firmware file system used to organize the firmware volume data. (i.e. FAT 32)

– Pluggable file system abstraction

• Firmware volumes (FV)– Location and media independence

• Code and data location need not be determined at build time– Dispatcher and BDS can use FV, File or network to find

required components

– Can change packaging based on platform needs

Framework Code and Data Storage



File System for FLASH Devices

FLASH Devices

Chipset Resources

PCI Devices

System Memory

0x0000 0000

0xFFFF FFFF (4GB)

Boot Firmware Volume

Main Firmware Volume

File #1

File #2. . .

File #n

Section #1

Section #2

Section #1

Section #2

• Flexible FLASH Layout• Flat File System

– Files Named by GUID– Updateable

• Extensible File Format



Firmware Volume

• The Firmware Volume is the basic firmware storage abstraction– Read only until read/write DXE driver loads

• Implemented as layered protocols– Firmware Volume protocol (abstracts

formatting of firmware device)– Firmware Volume Block protocol (abstracts

firmware device hardware and partitioning)

• Firmware File System– Space-optimized binary flat format– Architectural for PEI

Firmware Volume

Driver

Firmware Volume

Block Driver

Firmware Storage

Device

Low level

interface

File level

interface

Storage Definition enables modularityStorage Definition enables modularityStorage Definition enables modularityStorage Definition enables modularity




FV Update Goals

• Generic interface to update mechanism– Common default human interface

• OEM may supply their own– Self describing and use a common format

• No more special purpose tools to support, maintain, learn– Ideally just another OS Control Panel applet

• Scalable integrity framework– Interface should enable a range of mechanisms to prevent viral

attack on FVs




Capsules• Package of data in a known format

– Some used by OS

• Associated revision data, titles and etc. displayed by application

– Some used by Firmware

• New modules

• Programs

• Reuse definitions and code from firmware volumes

• Capsules are a way for the OS to provide DXE drivers to be run at the next reboot– Firmware update is an application of Capsules

• So is Recovery

– Other non-architectural mechanisms to support update and recovery may be provided as value-add




Capsule StructureCapsule

Capsule Header Header – used by OS present application, not loaded into RAM

Capsule volume (“CV”) Image – firmware volume with a different type GUID

Firmware Volume (“FV”) file: a firmware volume stored as a single file

Security ‘wrapper’ – for example, a digital signature of the contents to be validated while processing the CV

“Capsule Payload”: Various files. Can include executable DXE drivers, images, etc. In the case of update, might include both the image to update and the drivers to perform the update

Parameter file – file generated by Setup, path data, etc.

Capsule Volume Image

Firmware Volume File

Security Wrapper (optional)

Parameter File

Capsule Payload




From CV to FV2. Make capsule volume from CV image

Capsule Volume

Security Wrapper

Parameter File

Capsule

Payload

FV File

3. Validate security

Capsule Volume

Parameter File

Capsule

PayloadFV File

4. Create new RAM Firmware Volume from FV File

Capsule

Payload

Firmware Volume

5. Write non-executable (hence non-viral) param files

Capsule

PayloadFirmware Volume

Parameter File

The security wrapper is optional. An alternative, which would preserve or even add security, would be to sign each driver. Security requirements are defined by platform policy.

At #4, the dispatcher will scan the files in the new FV, discovering drivers to schedule.

CV image

Security Wrapper

Parameter File

Capsule

Payload

1. Load CV image into RAM

FV File




Storage Summary

• Standard storage enables modularity– Drivers don’t need to know about FLASH specifics– Modules from different vendors can co-exist in one

FLASH

• Efficient FLASH utilization• Support multiple FLASH devices• Modular Fault Tolerant Updates




Demo

• Loading Drivers from non-FLASH locations



Q & A



Back up

Firmware Storage : Technical Overview Copyright © 2006-2008 Intel Corporation Intel Corporation...

Documents

Transcript of Firmware Storage : Technical Overview Copyright © 2006-2008 Intel Corporation Intel Corporation...