13. Security (SEC) Phase Information

13.1. Introduction

The Security (SEC) phase is the first phase in the PI Architecture architecture and is responsible for the following:

• Handling all platform restart events

• Creating a temporary memory store

• Serving as the root of trust in the system

• Passing handoff information to the PEI Foundation

In addition to the minimum architecturally required handoff information, the SEC phase can pass optional information to the PEI Foundation, such as the SEC Platform Information PPI or information about the health of the processor.

The tasks listed above are common to all processor microarchitectures. However, there are some additions or differences between IA-32 and Itanium processors, which are discussed in Processor-Specific Details.

13.2. Responsibilities

13.2.1. Handling All Platform Restart Events

The Security (SEC) phase is the unit of processing that handles all platform restart events, including the following:

• Applying power to the system from an unpowered state

• Restarting the system from an active state

• Receiving various exception conditions

The SEC phase is responsible for aggregating any state information so that some PEIM can deduce the health of the processor upon the respective restart.

13.2.2. Creating a Temporary Memory Store

The Security (SEC) phase is also responsible for creating some temporary memory store. This temporary memory store can include but is not limited to programming the processor cache to behave as a linear store of memory. This cache behavior is referred to as “no evictions mode” in that access to the cache should always represent a hit and not engender an eviction to the main memory backing store; this “no eviction” is important in that during this early phase of platform evolution, the main memory has not been configured and such as eviction could engender a platform failure.

13.2.3. Serving As the Root of Trust in the System

Finally, the Security (SEC) phase represents the root of trust in the system. Any inductive security design in which the integrity of the subsequent module to gain control is corroborated by the caller must have a root, or “first,” component. For any PI Architecture deployment, the SEC phase represents the initial code that takes control of the system. As such, a platform or technology deployment may choose to authenticate the PEI Foundation from the SEC phase before invoking the PEI Foundation.

13.2.4. Passing Handoff Information to the PEI Foundation

Regardless of the other responsibilities listed in this section, the Security (SEC) phase’s final responsibility is to convey the following handoff information to the PEI:

• State of the platform

• Location and size of the Boot Firmware Volume (BFV)

• Location and size of the temporary RAM

• Location and size of the stack

• Optionally, one or more HOBs via the EFI_SEC_HOB_DATA_PPI

This handoff information listed above is passed to the PEI as arguments to the PEI Foundation entry point described in PEI Foundation Entry Point. The location of the BFV will be superseded by EFI_PEI_CORE_FV_LOCATION_PPI if that exists.

13.3. SEC Platform Information PPI

Handoff information is passed from the Security (SEC) phase to the PEI Foundation using the EFI_SEC_PEI_HAND_OFF structure and the list of PPI descriptors passed to the PEI entry point. One of these PPIs, EFI_SEC_PLATFORM_INFORMATION_PPI , can be used to pass handoff information from SEC to the PEI Foundation. This PPI abstracts platform-specific information that the PEI Foundation needs to discover where to begin dispatching PEIMs.

13.4. SEC HOB Data PPI

HOB data can be passed forward from the SEC phase to PEI or DXE consumers using HOBs. If the EFI_SEC_HOB_DATA_PPI is in the list of PPIs passed to the PEI entry point, the PEI Foundation will call the GetHobs() member function and installed all HOBs returned into the HOB list. It does this after installing all PPIs passed from SEC into the PPI database and before dispatching any PEIMs.

13.5. Health Flag Bit Format

The Health flag contains information that is generated by microcode, hardware, and/or the Itanium processor Processor Abstraction Layer (PAL) code about the state of the processor upon reset. Type EFI_HEALTH_FLAGS is defined in SEC_PLATFORM_INFORMATION_PPI.PlatformInformation() .

In an Itanium®-based system, the Health flag is passed from PAL-A after restarting. It is the means by which the PAL conveys the state of the processor to the firmware, such as PI. The handoff state is separated between the PAL and PI because the code is provided by different vendors; Intel provides the PAL and various OEMs design the PI firmware.

The Health flag is used by both IA-32 and Itanium architectures, but Tested (Te) is the only common bit. IA-32 has the built-in self-test (BIST), but none of the other capabilities.

Health Flag Bit Format depicts the bit format in the Health flag.

Fig. 13.1 Health Flag Bit Format

Health Flag Bit Field Description explains the bit fields in the Health flag. IA-32 ignores all bits except Tested (Te).

Table 13.1 Health Flag Bit Field Description

Field	Parameter Name in EFI_HEALTH_FLAGS	Bit	Description
State	Status	0 1	A 2 bit field indicating self test state after reset For more information see Self-Test State Parameter
Te	Tested	2	A 1 bit field indicating whether testing has occurred If this field is zero the processor has not been tested and no further fields in the self test State parameter are valid
Vm	VirtualMemoryUnavailable	16	A 1 bit field If set to 1 indicates that virtual memory features are not available
Ia	Ia32ExecutionUnavailable	17	A 1 bit field If set to 1 indicates that IA 32 execution is not available
Fp	FloatingPointUnavailable	18	A 1 bit field If set to 1 indicates that the floating point unit is not available
Mf	MiscFeaturesUnavailable	19	A 1 bit field If set to 1 indicates miscellaneous functional failure other than vm ia or fp The test status field provides additional information on test failures when the State field returns a value of performance restricted or functionally restricted The value returned is implementation dependent

13.5.1. Self-Test State Parameter

Self-test state parameters are defined in the same format for IA-32 Intel® processors and the Intel® Itanium® processor family. Some of the test status bits may not be relevant to IA-32 processors. In that case, these bits will read NULL on IA-32 processors.

Self-Test State Bit Values indicates the meanings for various values of the self-test State parameter (bits 0:1) of the Health flag.

Table 13.2 Self-Test State Bit Values

State	Value	Description
Catastrophic Failure	N/A	Processor is not executing.
Healthy	00	No failure in functionality or performance.
Performance Restricted	01	No failure in functionality but performance is restricted.
Functionally Restricted	10	Some code may run but functionality is restricted and performance may also be affected.

If the state field indicates that the processor is functionally restricted, then the vm, ia, and fp fields in the Health flag specify additional information about the functional failure. See Health Flag Bit Field Description for a description of these fields.

To further qualify “Functionally Restricted,” the following requirements will be met:

• The processor or PAL (for the Itanium processor family) has detected and isolated the failing component so that it will not be used.

• The processor must have at least one functioning memory unit, arithmetic logic unit (ALU), shifter, and branch unit.

• The floating-point unit may be disabled.

• For the Itanium processor family, the Register Stack Engine (RSE) is not required to work, but register renaming logic must work properly.

• The paths between the processor-controlled caches and the register files must work during the tests.

• Loads from the firmware address space must work correctly.

13.6. Processor-Specific Details

13.6.1. SEC Phase in IA-32 Intel Architecture

In 32-bit Intel® architecture (IA-32), the Security (SEC) phase of the PI Architecture is responsible for several activities:

• Locating the PEI Foundation

• Passing control directly to PEI using an architecturally defined handoff state

• Initializing processor-controlled memory resources, such as the processor data cache, that can be used as a linear extent of memory for a call stack (if supported)

PEI Initialization Steps in IA-32 below shows the steps completed during PEI initialization for IA-32.

Fig. 13.2 PEI Initialization Steps in IA-32

13.6.2. SEC Phase in the Itanium Processor Family

Itanium architecture contains enough hooks to authenticate the PAL-A and PAL-B code distributed by the processor vendor.

The internal microcode on the processor silicon that starts up on a power-good reset finds the first layer of processor abstraction code (called PAL-A) located in the Boot Firmware Volume (BFV) using architecturally defined pointers in the BFV. It is the responsibility of this microcode to authenticate that the PAL-A code layer from the processor vendor has not been tampered.

If the authentication of the PAL-A layer passes, then control passes on to the PAL-A layer. The PAL-A layer then authenticates the next layer of processor abstraction code (called PAL-B) before passing control to it.

In addition, the SEC phase of the PI Architecture is also responsible for locating the PEI Foundation and verifying its authenticity.

Security (SEC) Phase in the Itanium ProcessorFamily summarizes the SEC phase in the Itanium® processor family.

Fig. 13.3 Security (SEC) Phase in the Itanium ProcessorFamily