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.