Skip to content

Configuration Profiles (BIOS Flavors) Implementation

Table of Contents

[[TOC]]

Description

This document describes the requirements, design considerations and APIs for UEFI Configuration Profiles

Revision History

Revised by Date Changes
Oliver Smith-Denny 09/15/2022 Initial design

Terms

Term Description
UEFI Unified Extensible Firmware Interface
DFCI Device Firmware Configuration Interface
MFCI Manufacturer Firmware Configuration Interface
FV Firmware Volume

Reference Documents

Document Link
MFCI Documentation Link
DFCI Documentation Link
UEFI Variable Policy Whitepaper Link
SetupVariable Flow Link
Configuration YAML Spec https://slimbootloader.github.io/specs/config.html#configuration-description-yaml-explained

Introduction

Configuration Profiles

UEFI Configuration Profiles, historically called BIOS Flavors, are sets of defined values for UEFI configuration variables. Such profiles are useful where different owners may use the same hardware but have different requirements for UEFI configuration variables, such as one owner requiring Secure Boot enabled and SMT disabled and another owner requiring Secure Boot disabled and SMT enabled. Configuration profiles are provided by the FW as a means to allow both groups to use the same hardware and FW, but choosing different profiles with the set of configuration they require.

Design

Flow

There will be one generic profile that describes the default values for all UEFI configuration variables. This generic profile will be generated during build time from one YAML configuration file specified in PlatformBuild.py as YAML_CONF_FILE. Additional profiles will be represented as delta files (.dlt files generated by the ConfigEditor UI tool) with the profile name as the filename. These will be a semicolon delimited list in PlatformBuild.py under the name DELTA_CONF_POLICY. During build time, the GenSetupDataBin.py build plugin will generate variable list binaries describing each profile under the build variables CONF_BIN_FILE_0 ... CONF_BIN_FILE_N. These are expected to be consumed in the platform FDF under the profile GUIDs, where gSetupDataPkgGenericProfileGuid must have a corresponding entry.

The platform will override gSetupDataPkgTokenSpaceGuid.PcdConfigurationProfileList as a FixedAtBuild PCD in their dsc file with a list of the valid profile GUIDs that exist for that platform. Any received or cached active profile GUIDs will be validated against this list. If they are not in this list, gSetupDataPkgGenericProfileGuid will be used as the active profile GUID.

Platform owners can develop a configuration profile for their use case. Following examples and the format provided in the ConfigurationFiles doc, these owners can create a YAML delta file describing the set of configuration variables and their values that are in the profile that differ from the generic profile. The ConfigEditor UI tool may be used to assist in loading the YAML and saving the output into delta files, as well as manipulating the values as necessary.

The profiles will be used as overrides to the silicon policy published earlier in the boot. It is the responsibility of the drivers that map platform configuration to silicon policy to consume the platform configuration variables. In DXE, the ActiveProfileSelectorLib library class is queried to return the active profile file GUID to use for this boot. ConfProfileMgrDxe will compare this profile GUID against what is loaded into the variable store. If the profile does not match, ConfProfileMgrDxe will write the chosen profile variables into the variable store and reboot the system. The profiles will define the entire set of UEFI configuration variables.

Profile Update

Profiles will only be added and have values updated during build time.

If a new configuration knob is required to be added to the configuration profile, it must go into the generic profile with a default value in addition to whichever profiles choose to override it.

If a configuration knob is required to change to a new value with the same structure, it can simply be updated using the Config Editor UI tool to the new value.

If a new structure is required for an existing configuration knob, then it is required that a new configuration knob be added, with the old knob being removed as soon as feasible.

Active Profile Selection

The ActiveProfileSelectorLib library class is intended to have the platform override the value. It will retrieve the active profile file GUID. If ActiveProfileSelectorLib has a failure or returns a file GUID not in gSetupDataPkgTokenSpaceGuid.PcdConfigurationProfileList, ConfProfileMgrDxe will attempt to fall back to the last used profile, if one exists. If the cached profile is not found or has an invalid value, ConfProfileDxe will use the generic profile, under the GUID gSetupDataPkgGenericProfileGuid, as the active profile.

A given platform should override the ActiveProfileSelectorLib library class to retrieve the active profile file GUID from their source of truth.

Profile Enforcement

In MFCI Customer Mode, the active profile will be enforced on every boot. If the variable store has any values that are invalid according to the profile, ConfProfileMgrDxe will write the profile values and reset the system.

In MFCI Manufacturing Mode, the active profile will not be enforced. ConfProfileMgrDxe will not attempt to validate the variable store contents against the profile values.