microsoft / mu_feature_config

Project Mu - Feature Repo - UEFI User Config and Management Support

Project Mu Configuration Repository

Host Type & Toolchain	Build Status	Test Status	Code Coverage
Windows_VS
Ubuntu_GCC5

This repository is part of Project Mu. Please see Project Mu for details https://microsoft.github.io/mu

This Configuration feature repo contains the generic Config Editor tools from Intel's Slim Bootloader repo which has been refactored to support more general use and with added functionality.

Detailed Feature Information

Far more details about using this repo can be found in: Configuration Applications Design.

Repository Philosophy

Like other Project MU feature repositories, the Project MU Configuration feature repo does not strictly follow the EDKII releases, but instead has a continuous main branch which will periodically receive cherry-picks of needed changes from EDKII. For stable builds, release tags will be used instead to determine commit hashes at stable points in development. Release branches may be created as needed to facilitate a specific release with needed features, but this should be avoided.

Consuming the Configuration Feature Package

Since this project does not follow the release fork model, the code should be consumed from a release hash and should be consumed as a extdep in the platform repo. To include, create a file named feature_config_ext_dep.yaml desired release tag hash. This could be in the root of the project or in a subdirectory as desired.

{

"scope": "global",

"type": "git",

"name": "FEATURE_CONFIG",

"var_name": "FEATURE_CONFIG_PATH",

"source": "https://github.com/microsoft/mu_feature_config.git",

"version": "<RELEASE HASH>",

"flags": ["set_build_var"]

}

Setting the the var_name and the set_build_var flags will allow the build scripts to reference the extdep location. To make sure that the package is discoverable for the build, the following line should also be added to the build configurations GetPackagesPath list.

shell_environment.GetBuildVars().GetValue("FEATURE_CONFIG_PATH", "")

Note: If using pytool extensions older then version 0.17.0 you will need to append the root path to the build variable string.

After this the package should be discoverable to can be used in the build like any other dependency.

SetupDataPkg's Tools

The SetupDataPkg/Tools folder contains Utilities that can enable working with Setup data

Utility	Usage
SetupDataPkg/Tools/ConfigEditor.py	Configuration utility for creating/modifying SVD,XML configurations
SetupDataPkg/Tools/GenCfgData.py	Utility to generate output configuration structres from input YAML configurations
SetupDataPkg/Tools/VariableList.py	Utility to generate EFI dmpstore foramtted binaries, or csv file based on XML configuration
SetupDataPkg/Tools/WrapAndSetSvd.py	Utility to generate Dfci formatted output from input SVD file.

Code of Conduct

This project has adopted the Microsoft Open Source Code of Conduct https://opensource.microsoft.com/codeofconduct/

For more information see the Code of Conduct FAQ https://opensource.microsoft.com/codeofconduct/faq/ or contact [email protected]. with any additional questions or comments.

Contributions

Contributions are always welcome and encouraged! Please open any issues in the Project Mu GitHub tracker and read https://microsoft.github.io/mu/How/contributing/

• [Code Requirements](https://microsoft.github.io/mu/CodeDevelopment/requirements/)
• [Doc Requirements](https://microsoft.github.io/mu/DeveloperDocs/requirements/)

Issues

Please open any issues in the Project Mu GitHub tracker. [More Details](https://microsoft.github.io/mu/How/contributing/)

Builds

Please follow the steps in the Project Mu docs to build for CI and local testing. [More Details](https://microsoft.github.io/mu/CodeDevelopment/compile/)

Copyright & License

Copyright (C) Microsoft Corporation

SPDX-License-Identifier: BSD-2-Clause-Patent

Upstream License (Slim Bootloader)

Copyright (c) 2019, Intel Corporation and contributors. All rights reserved.

SPDX-License-Identifier: BSD-2-Clause-Patent

Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met:

1. Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer.
2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution.

Subject to the terms and conditions of this license, each copyright holder and contributor hereby grants to those receiving rights under this license a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable (except for failure to satisfy the conditions of this license) patent license to make, have made, use, offer to sell, sell, import, and otherwise transfer this software, where such license applies only to those patent claims, already acquired or hereafter acquired, licensable by such copyright holder or contributor that are necessarily infringed by:

1. their Contribution(s) (the licensed copyrights of copyright holders and non-copyrightable additions of contributors, in source or binary form) alone; or
2. combination of their Contribution(s) with the work of authorship to which such Contribution(s) was added by such copyright holder or contributor, if, at the time the Contribution is added, such addition causes such combination to be necessarily infringed. The patent license shall not apply to any other combinations which include the Contribution.

Except as expressly stated above, no rights or licenses from any copyright holder or contributor is granted under this license, whether expressly, by implication, estoppel or otherwise.

DISCLAIMER

THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDERS OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

mu_feature_config's Issues

[Feature]: Improve Enum support

Feature Overview

Enums naming, and enum value naming, is limited. The enums names are limited by the function is_valid_name(), which tries to limit the names to C compatible names. Given that enums are not a c struct, and will not be generated into C code, these limitations should not exist.

Example:

Problem:
A name starting with a digit is now allowed.

Example:

Problem:
Spaces are not allowed in Value Names

Example:

Solution Overview

New function to enable c identifier compliance checking ( is_valid_c_identifier)
Modify existing function is_valid_name to allow for useful information (spaces, parentheses and starting with digits)

Alternatives Considered

No response

Urgency

Medium

Are you going to implement the feature request?

I will implement the feature

Do you need maintainer feedback?

No maintainer feedback needed

Anything else?

No response

[Documentation]: Using ConfigEditor to generate individual profiles

Request Description

Can the documentation be updated to show how to use the ConfigEditor to generate an individual profile CSV file?

Are you going to make the change?

Someone else needs to make the change

Do you need maintainer feedback?

No maintainer feedback needed

Anything else?

No response

[Feature]: Adopt semantic versioning

Feature Overview

The request is to adopt semantic versioning in this repository.

This is similar to other Project Mu repos that have such as:

• mu_basecore
• mu_feature_dfci
• mu_tiano_platforms
• mu_devops

This allows consumers to more easily ingest releases per the goals of the semantic versioning specification.

It also allows workflows in Mu DevOps to operate on the repo such as:

• Release Drafter
• Submodule Version Updater

Solution Overview

Switch repository versioning to comply with the Semantic Versioning 2.0.0 Specification.

Alternatives Considered

Keep as-is. This has the disadvantage of inconsistent versioning limiting compatibility with tools and consuming processes.

Urgency

Low

Are you going to implement the feature request?

Someone else needs to implement the feature

Do you need maintainer feedback?

Maintainer feedback requested

Anything else?

No response

[Feature]: Only list delta items in configuration item level in CSV file instead of putting all items of a structure

Feature Overview

List only the delta of configuration field in CSV compare to generic xml file instead of listing the whole structure in CSV file.
In the past with YAML/DLT design, we can just list delta of configuration item in DLT file, but now with XML/CSV design, if an item is under one structure, it needs to list the delta in structure level instead of the actual configuration item.
In a product development, when we touch the XML file, it cannot guarantee the CSV file list is compatible with the new updated XML file, so everytime when the XML get updated, the CSV file also need to be re-generated by ConfigEditor.py tool.

Solution Overview

Align with the original YAML/DLT experience that only need to list the delta in configuration item level instead of structure level in XML/CSV design

Alternatives Considered

No response

Urgency

Medium

Are you going to implement the feature request?

Someone else needs to implement the feature

Do you need maintainer feedback?

Maintainer feedback requested

Anything else?

No response

[Feature]: improve CSV processing and error messges

Feature Overview

When dealing with multiple CSV files for profile support, error messages are sparse (i.e. the specific filename being processed is not displayed, and this can result in difficulty in finding the offending code.

Other minor annoyances:

in CSV profile, having a blank line at the end of the file causes tool failure:

INFO -   File "C:\Code\mu_tiano_platforms\Features\CONFIG\SetupDataPkg\Tools\VariableList.py", line 1201, in read_csv
INFO -     knob_value_string = row[value_index]

Enum Knob override in Profile CSV cannot have a leading space. Example:

Modify CfgData.xml in Q35 to add enum and enum knob. Same limitation doesn't exist for

   <Enums>
    <Enum name="EnableDisableCombo" help="">
      <Value name="Disabled" value="0" help="" />
      <Value name="Enabled"  value="1" help="" />
    </Enum>
   </Enums>
   
    <Knob name="ExampleEnum" type="EnableDisableCombo" default="Enabled" help="" />

in CfgData.csv, add override with leading space:

*,ExampleEnum, Disabled,00 00 00 00,

INFO -   File "C:\Code\mu_tiano_platforms\Features\CONFIG\SetupDataPkg\Tools\VariableList.py", line 365, in string_to_object
INFO -     raise ParseError(
INFO - VariableList.ParseError: Value ' Disabled' is not a valid value of enum 'EnableDisableCombo'

enum values are a maximum of uint32_t, which is in conflict with flexibility of yaml.
Would it be possible to specify a size for enums? or to increase their default size to uint64_t to account for larger values that need storing?

Solution Overview

Minor changes/improvements

Alternatives Considered

No response

Urgency

Low

Are you going to implement the feature request?

I will implement the feature

Do you need maintainer feedback?

No maintainer feedback needed

Anything else?

No response

[Bug]: Cannot use ConfigGet*** APIs from ConfigClientGenerated.h in Pre-Memory envrionment

Is there an existing issue for this?

• I have searched existing issues

Current Behavior

If the ConfigPolicyTo[Silicon|Platform]Mapper driver get dispatched in Pre-Memory phase, when we try to use ConfigGet*** APIs from ConfigClientGenerated.h to retrieve the config back, all the data is 0 due to the memory is still not ready to use, and in each ConfigGet*** APIs, it calls InitConfigPolicyCache() to get CloudConfigPolicy and store in CachedPolicy, which is a global variable in C code, so in Pre-Memory phase, the global variable cannot be updated success, all the data will be kept as 0.

Expected Behavior

To make the design generic and can be adopted to all system architecture, needs to consider the case that ConfigPolicyTo[Silicon|Platform]Mapper get dispatched in Pre-Memory phase, and ConfigGet*** APIs from ConfigClientGenerated.h should work properly in Pre-Memory environment, so global variables consumption in Pre-Memory phase should be prevented.

Steps To Reproduce

Call ConfigGet*** APIs from ConfigClientGenerated.h, the return status is success, but all the data we retrieved will still be zero.

Build Environment

- OS(s): Windows 11
- Tool Chain(s): VS2022
- Targets Impacted: RELEASE, DEBUG

Version Information

v1.0.0

Urgency

High

Are you going to fix this?

Someone else needs to fix it

Do you need maintainer feedback?

Maintainer feedback requested

Anything else?

No response

[Bug]: Newlines missing from set variable auto-generated functions

Is there an existing issue for this?

• I have searched existing issues

Current Behavior

With the input xml example below, SetupDataPkg/Tools/KnobService.py generates the following output in the private header file.

The setter function is missing a couple of new lines and isn't properly formatted.

Input XML:

<ConfigSchema xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
 xsi:noNamespaceSchemaLocation="configschema.xsd">
  <!-- namespace indicates the GUID namespace the values are stored in -->
  <Knobs namespace="{5db63705-b75f-429b-a331-0fe95af09e19}">
    <!-- configuration knobs -->
    <Knob name="example" type="bool" help="Example help" />
    <!-- end configuration knobs -->
  </Knobs>
</ConfigSchema>

Output:

#ifdef CONFIG_SET_VARIABLES
// Set the current value of the example knob
bool config_set_example(bool value) {    return set_knob_value(KNOB_example, &value);
}
#endif // CONFIG_SET_VARIABLES

Expected Behavior

The generated setter output should look like something like this:

#ifdef CONFIG_SET_VARIABLES
// Set the current value of the example knob
bool config_set_example(bool value) {    
    return set_knob_value(KNOB_example, &value);
}
#endif // CONFIG_SET_VARIABLES

Steps To Reproduce

Use the example xml above to auto-generate configuration knob header files using SetupDataPkg/Tools/KnobService.py. The setter-function in the private header file (priv_hdr.h) will be malformed.

KnobService.py generateheader example.xml pub_hdr.h priv_hdr.h

Build Environment

- OS(s): Ubuntu 20.04
- Tool Chain(s): gcc-arm-10.2-2020.11
- Targets Impacted: RELEASE, DEBUG

Version Information

Commit: ae681b2

Urgency

Medium

Are you going to fix this?

Someone else needs to fix it

Do you need maintainer feedback?

No maintainer feedback needed

Anything else?

No response

[Bug]: Contract of autogen header data variables and the consumers

Is there an existing issue for this?

• I have searched existing issues

Current Behavior

Currently, the autogen headers would produce 4 global variables, which ideally will be included in a data library for a module to produce the final content in the policy service (see implementation in OEM sample package). However, these global variables are being referenced by consumers through externs. This starts to cause the downstream users to change such content and make the localized PR work without updating the autogen script.

Expected Behavior

This ticket is logged to fill in the contract of autogen variables and their users, so that the data library update will need to originate from the autogen script. And also fix a downstream request of adding the support of profile names.

Steps To Reproduce

Just run the autogen header creator. OEM sample can update their referenced global variables and still pass the build. But the platforms that consume the autogen pipeline will break the build because the linker will fail.

Build Environment

- OS(s): Ubuntu 22.04
- Tool Chain(s): GCC5
- Targets Impacted: DEBUG, RELEASE

Version Information

Top of main.

Urgency

High

Are you going to fix this?

I will fix it

Do you need maintainer feedback?

No maintainer feedback needed

Anything else?

No response

[Feature]: Add DXE_SMM_DRIVER support or ConfigKnobShimLib

Feature Overview

The ConfigKnobShimLib only supports MM_STANDALONE module type, but in x86, the system may also need to get config under SMM mode.

Solution Overview

1. Add DXE_SMM_DRIVER in ConfigKnobShimStandaloneMmLib.inf
2. Rename ConfigKnobShimMmLib.inf to ConfigKnobShimMmLib.inf to support both Traditional and Standalone MM, please refer to MmPolicyLib of PolicyServicePkg as reference.

Alternatives Considered

No response

Urgency

Medium

Are you going to implement the feature request?

Someone else needs to implement the feature

Do you need maintainer feedback?

Maintainer feedback requested

Anything else?

No response