## Description
4.0.5 updates the GitHub Actions used for labeling to include a
bug fix for previous versions trying to delete a label that does not
exist.
- [ ] Impacts functionality?
- **Functionality** - Does the change ultimately impact how firmware
functions?
- Examples: Add a new library, publish a new PPI, update an algorithm,
...
- [ ] Impacts security?
- **Security** - Does the change have a direct security impact on an
application,
flow, or firmware?
- Examples: Crypto algorithm change, buffer overflow fix, parameter
validation improvement, ...
- [ ] Breaking change?
- **Breaking change** - Will anyone consuming this change experience a
break
in build or boot behavior?
- Examples: Add a new library class, move a module to a different repo,
call
a function in a new library class in a pre-existing module, ...
- [ ] Includes tests?
- **Tests** - Does the change include any explicit test code?
- Examples: Unit tests, integration tests, robot tests, ...
- [ ] Includes documentation?
- **Documentation** - Does the change contain explicit documentation
additions
outside direct code modifications (and comments)?
- Examples: Update readme file, add feature readme file, link to
documentation
on an a separate Web page, ...
## How This Was Tested
Already enabled in release/202302 and resolves a workflow error
encountered in the label task.
## Integration Instructions
N/A - Integrated in this change
Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com>
## Description
Cherry-pick from release/202202 (commit
[d484285](d484285210)).
Read FV header length from the header instead of using
`sizeof(EFI_FIRMWARE_VOLUME_HEADER)` to account for variable number
of block map entries.
- [x] Impacts functionality?
- **Functionality** - Does the change ultimately impact how firmware
functions?
- Examples: Add a new library, publish a new PPI, update an algorithm,
...
- [ ] Impacts security?
- **Security** - Does the change have a direct security impact on an
application,
flow, or firmware?
- Examples: Crypto algorithm change, buffer overflow fix, parameter
validation improvement, ...
- [ ] Breaking change?
- **Breaking change** - Will anyone consuming this change experience a
break
in build or boot behavior?
- Examples: Add a new library class, move a module to a different repo,
call
a function in a new library class in a pre-existing module, ...
- [ ] Includes tests?
- **Tests** - Does the change include any explicit test code?
- Examples: Unit tests, integration tests, robot tests, ...
- [ ] Includes documentation?
- **Documentation** - Does the change contain explicit documentation
additions
outside direct code modifications (and comments)?
- Examples: Update readme file, add feature readme file, link to
documentation
on an a separate Web page, ...
## How This Was Tested
(cherry-pick from release/202202)
## Integration Instructions
N/A other than including this change.
Updates the requirements on
[edk2-pytool-extensions](https://github.com/tianocore/edk2-pytool-extensions)
to permit the latest version.
Signed-off-by: dependabot[bot] <support@github.com>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Updates the requirements on
[edk2-pytool-extensions](https://github.com/tianocore/edk2-pytool-extensions)
to permit the latest version.
Signed-off-by: dependabot[bot] <support@github.com>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Updates the requirements on
[edk2-pytool-extensions](https://github.com/tianocore/edk2-pytool-extensions)
to permit the latest version.
Signed-off-by: dependabot[bot] <support@github.com>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Updates the requirements on
[edk2-pytool-extensions](https://github.com/tianocore/edk2-pytool-extensions)
to permit the latest version.
Signed-off-by: dependabot[bot] <support@github.com>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Updates the requirements on
[edk2-pytool-extensions](https://github.com/tianocore/edk2-pytool-extensions)
to permit the latest version.
Signed-off-by: dependabot[bot] <support@github.com>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Makes integer width consistent in loop conditions and explicitly
checks for NULL pointers in some places.
Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com>
Makes integer width consistent in loop conditions and explicitly
checks for NULL pointers in some places.
Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com>
## Description
This will pick up filters from repo dependencies like mu_basecore.
- [ ] Impacts functionality?
- **Functionality** - Does the change ultimately impact how firmware functions?
- Examples: Add a new library, publish a new PPI, update an algorithm, ...
- [ ] Impacts security?
- **Security** - Does the change have a direct security impact on an application,
flow, or firmware?
- Examples: Crypto algorithm change, buffer overflow fix, parameter
validation improvement, ...
- [ ] Breaking change?
- **Breaking change** - Will anyone consuming this change experience a break
in build or boot behavior?
- Examples: Add a new library class, move a module to a different repo, call
a function in a new library class in a pre-existing module, ...
- [ ] Includes tests?
- **Tests** - Does the change include any explicit test code?
- Examples: Unit tests, integration tests, robot tests, ...
- [ ] Includes documentation?
- **Documentation** - Does the change contain explicit documentation additions
outside direct code modifications (and comments)?
- Examples: Update readme file, add feature readme file, link to documentation
on an a separate Web page, ...
## How This Was Tested
CI build with `--codeql` flag.
## Integration Instructions
N/A - Affects CodeQL results in this repo
Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com>
synced local file(s) with [microsoft/mu_devops](https://github.com/microsoft/mu_devops).
🤖: View the [Repo File Sync Configuration File](https://github.com/microsoft/mu_devops/blob/main/.sync/Files.yml) to see how files are synced.
---
Adds a new workflow that is synced to Mu repos that are
currently expected to run against CodeQL.
This workflow has the following features to support
maintainability across the repos it is synced to:
- The packages are auto discovered and a dynamic matrix
is generated for each package build. This allows the
same file to work as-is in each repo that performs
CI builds (packages are in the repo root directory).
- The Mu Basecore plugin directory is auto discovered
in the workspace based on the presence of the CodeQL
plugin being present in the directory.
- The operations supported by the Stuart CI script are
dynamically discovered.
- CodeQL is only run on Windows agents. There is a known
issue when building edk2-style code on Linux so this
avoids encountering that issue.
See: https://github.com/github/codeql-action/issues/1338
- The Windows CodeQL CLI package is about 260MB at this time.
The GitHub Action cache is used by this workflow to cache
the CLI after it is initially pulled down in the Stuart ext
dep update.
- The CLI ext dep directory name and version used for caching
are read from the ext_dep YAML file to reduce maintenance
needed in the workflow if the file changes in the future.
Note that the SARIF file for each run is uploaded as a per-package
artifact. These can be downloaded and opened in VS Code with the
SARIF Viewer extension to view issues locally with the ability
to click to issue locations in files.
Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com>
---
This PR was created automatically by the [repo-file-sync-action](https://github.com/BetaHuhn/repo-file-sync-action) workflow run [#4295514175](https://github.com/microsoft/mu_devops/actions/runs/4295514175)
Updates the requirements on
[edk2-pytool-extensions](https://github.com/tianocore/edk2-pytool-extensions)
to permit the latest version.
Signed-off-by: dependabot[bot] <support@github.com>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Updates the Standalone MM module to have the necessary INF changes
to build with the following two recent commits made to rewrite the
the variable store header in the MM SPI FVB service.
- e95c798
- 88d44c5
Cc: Ashraf Ali S <ashraf.ali.s@intel.com>
Cc: Isaac Oram <isaac.w.oram@intel.com>
Cc: Rangasai V Chaganty <rangasai.v.chaganty@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Cc: Chasel Chiu <chasel.chiu@intel.com>
Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com>
Reviewed-by: Isaac Oram <isaac.w.oram@intel.com>
Reviewed-by: Chasel Chiu <chasel.chiu@intel.com>
(cherry picked from commit e2353ad640d55dafb7315eae2a93b318809ccbe3)
Platform may implement an additional NVS region following
Regular variable region and in this case SpiFvbService should include
both region size when calculating the total NVS region size.
The PcdFlashNvStorageAdditionalSize is for compatible with legacy
usages that should be deprecated. The new usage model should define
separate regions without implicit connections to UEFI Variable or
FTW regions.
Example NVS flash map for such legacy usage:
Note: PcdFlashNvStorageAdditionalSize is equal to platform
PcdFlashFvNvStorageEventLogSize.
---------------
|UEFI Variable|
---------------
|EventLog | <= this is Additional NVS region
---------------
|FTW Working |
---------------
|FTW Spare |
---------------
Cc: Ashraf Ali S <ashraf.ali.s@intel.com>
Cc: Isaac Oram <isaac.w.oram@intel.com>
Cc: Rangasai V Chaganty <rangasai.v.chaganty@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Cc: Michael Kubacki <michael.kubacki@microsoft.com>
Signed-off-by: Chasel Chiu <chasel.chiu@intel.com>
Reviewed-by: Michael Kubacki <michael.kubacki@microsoft.com>
Reviewed-by: Isaac Oram <isaac.w.oram@intel.com>
(cherry picked from commit 88d44c563d9fd5c95be93e706f9420352ee4c053)
When invalid VariableStore FV header detected, current SpiFvbService
will erase both FV and VariableStore headers from flash, however,
it will only rewrite FV header back and cause invalid VariableStore
header.
This patch adding the support for rewriting both FV header and
VariableStore header when VariableStore corruption happened.
The Corrupted variable content should be taken care by
FaultTolerantWrite driver later.
Platform has to set PcdFlashVariableStoreType to inform SpiFvbService
which VariableStoreType should be rewritten.
Cc: Ashraf Ali S <ashraf.ali.s@intel.com>
Cc: Isaac Oram <isaac.w.oram@intel.com>
Cc: Rangasai V Chaganty <rangasai.v.chaganty@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Cc: Michael Kubacki <michael.kubacki@microsoft.com>
Signed-off-by: Chasel Chiu <chasel.chiu@intel.com>
Reviewed-by: Michael Kubacki <michael.kubacki@microsoft.com>
Reviewed-by: S, Ashraf Ali <ashraf.ali.s@intel.com>
Reviewed-by: Isaac Oram <isaac.w.oram@intel.com>
(cherry picked from commit e95c7988994c73918ffa282e2d2f5af11f8addc4)
## Description
Allows CodeQL to be run locally by specifying `--codeql` when
providing `stuart_update` and `stuart_ci_build` commands in this
repo.
- `stuart_update` - Automatically downloads the CodeQL CLI application
appropriate for your host operating system
- Note: This may take several minutes depending on your Internet
connection speed
- `stuart_ci_build` - Automatically runs CodeQL against the packages
built after they are built.
NOTE: Running with CodeQL will increase your overall build time for a
couple of reasons:
1. Every package must be clean built to get proper results
2. The CodeQL analysis phase takes a while to run
(1) happens automatically, you do not need to specify a clean build
manually
For more information, such as:
1. How to view results
2. How to modify the CodeQL rules run
3. How to include/exclude files/rules at various levels of granularity
And more...
Go to the CodeQL plugin readme:
https://github.com/microsoft/mu_basecore/blob/HEAD/.pytool/Plugin/CodeQL/Readme.md
---
Also, this commit sets `STUART_CODEQL_AUDIT_ONLY` to `TRUE`. This is
done to:
1. Demonstrate how to set an entire repo to audit-only mode
2. Allow CodeQL to run without breaking the build at this point in
source history since issues remain to be fixed on this branch
This will be removed from the file when (2) is completed.
---
- [ ] Impacts functionality?
- **Functionality** - Does the change ultimately impact how firmware functions?
- Examples: Add a new library, publish a new PPI, update an algorithm, ...
- [ ] Impacts security?
- **Security** - Does the change have a direct security impact on an application,
flow, or firmware?
- Examples: Crypto algorithm change, buffer overflow fix, parameter
validation improvement, ...
- [ ] Breaking change?
- **Breaking change** - Will anyone consuming this change experience a break
in build or boot behavior?
- Examples: Add a new library class, move a module to a different repo, call
a function in a new library class in a pre-existing module, ...
- [ ] Includes tests?
- **Tests** - Does the change include any explicit test code?
- Examples: Unit tests, integration tests, robot tests, ...
- [ ] Includes documentation?
- **Documentation** - Does the change contain explicit documentation additions
outside direct code modifications (and comments)?
- Examples: Update readme file, add feature readme file, link to documentation
on an a separate Web page, ...
## How This Was Tested
Verified `--codeql` usage with `stuart_update` and `stuart_ci_build` locally.
## Integration Instructions
See earlier PR description and CodeQL plugin readme:
https://github.com/microsoft/mu_basecore/blob/HEAD/.pytool/Plugin/CodeQL/Readme.md
Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com>
## Description
Add libraries needed to support /GS MSVC flag.
- [ ] Impacts functionality?
- **Functionality** - Does the change ultimately impact how firmware functions?
- Examples: Add a new library, publish a new PPI, update an algorithm, ...
- [ ] Impacts security?
- **Security** - Does the change have a direct security impact on an application,
flow, or firmware?
- Examples: Crypto algorithm change, buffer overflow fix, parameter
validation improvement, ...
- [ ] Breaking change?
- **Breaking change** - Will anyone consuming this change experience a break
in build or boot behavior?
- Examples: Add a new library class, move a module to a different repo, call
a function in a new library class in a pre-existing module, ...
- [ ] Includes tests?
- **Tests** - Does the change include any explicit test code?
- Examples: Unit tests, integration tests, robot tests, ...
- [ ] Includes documentation?
- **Documentation** - Does the change contain explicit documentation additions
outside direct code modifications (and comments)?
- Examples: Update readme file, add feature readme file, link to documentation
on an a separate Web page, ...
## How This Was Tested
Verified IntelFsp2Pkg VS2022 build.
## Integration Instructions
N/A - Local package build
Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com>
## Description
The /GS flag will not be added to VS2015 and VS2017 builds. This change removes the addition of stack cookie support libraries for VS2015 and VS2017 builds.
- [ ] Impacts functionality?
- **Functionality** - Does the change ultimately impact how firmware functions?
- Examples: Add a new library, publish a new PPI, update an algorithm, ...
- [ ] Impacts security?
- **Security** - Does the change have a direct security impact on an application,
flow, or firmware?
- Examples: Crypto algorithm change, buffer overflow fix, parameter
validation improvement, ...
- [ ] Breaking change?
- **Breaking change** - Will anyone consuming this change experience a break
in build or boot behavior?
- Examples: Add a new library class, move a module to a different repo, call
a function in a new library class in a pre-existing module, ...
- [ ] Includes tests?
- **Tests** - Does the change include any explicit test code?
- Examples: Unit tests, integration tests, robot tests, ...
- [ ] Includes documentation?
- **Documentation** - Does the change contain explicit documentation additions
outside direct code modifications (and comments)?
- Examples: Update readme file, add feature readme file, link to documentation
on an a separate Web page, ...
## How This Was Tested
N/A - VS2015 or VS2017 are no longer supported
## Integration Instructions
N/A
REF:https://bugzilla.tianocore.org/show_bug.cgi?id=4114
1.Use xmm5 slot 1 and xmm6 slot 3 to save ucode status and UPD pointer
respectively in TempRamInitApi in IA32 FspSecCoreT.
2.Correct inappropriate description in the return value of
AsmGetFspInfoHeader.
3.Replace hardcoded offset value 0x1C with FSP_HEADER_IMGBASE_OFFSET in
FspHeler.nasm.
Cc: Chasel Chiu <chasel.chiu@intel.com>
Cc: Nate DeSimone <nathaniel.l.desimone@intel.com>
Cc: Star Zeng <star.zeng@intel.com>
Cc: Ashraf Ali S <ashraf.ali.s@intel.com>
Cc: Chinni B Duggapu <chinni.b.duggapu@intel.com>
Signed-off-by: Ted Kuo <ted.kuo@intel.com>
Reviewed-by: Chasel Chiu <chasel.chiu@intel.com>
Reviewed-by: Nate DeSimone <nathaniel.l.desimone@intel.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4114
FSP specification supports input UPD as NULL cases which FSP will
use built-in UPD region instead.
FSP should not return INVALID_PARAMETER in such cases.
In FSP-T entry point case, the valid FSP-T UPD region pointer will be
passed to platform FSP code to consume.
In FSP-M and FSP-S cases, valid UPD pointer will be decided when
updating corresponding pointer field in FspGlobalData.
Cc: Nate DeSimone <nathaniel.l.desimone@intel.com>
Cc: Star Zeng <star.zeng@intel.com>
Signed-off-by: Chasel Chiu <chasel.chiu@intel.com>
Reviewed-by: Nate DeSimone <nathaniel.l.desimone@intel.com>
Reviewed-by: Ted Kuo <ted.kuo@intel.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4126
Common functions will have either 32bit or 64bit instances which
having different return code size. Function header should support both
scenarios.
Cc: Nate DeSimone <nathaniel.l.desimone@intel.com>
Cc: Star Zeng <star.zeng@intel.com>
Signed-off-by: Chasel Chiu <chasel.chiu@intel.com>
Reviewed-by: Nate DeSimone <nathaniel.l.desimone@intel.com>
## Description
A new identifier can be used to identify published artifacts (as
of mu_devops 2.0.0 release). This change passes the packages and
targets being built to clarify artifact names.
The default value for the identifier is "Artifacts" so that is
what is being used at the moment. For example, build logs are
published under `"Logs Artifacts"`. After this change, the
identifier will be `"Logs <packages> <targets>"`.
- [ ] Impacts functionality?
- **Functionality** - Does the change ultimately impact how firmware functions?
- Examples: Add a new library, publish a new PPI, update an algorithm, ...
- [ ] Impacts security?
- **Security** - Does the change have a direct security impact on an application,
flow, or firmware?
- Examples: Crypto algorithm change, buffer overflow fix, parameter
validation improvement, ...
- [x] Breaking change?
- **Breaking change** - Will anyone consuming this change experience a break
in build or boot behavior?
- Examples: Add a new library class, move a module to a different repo, call
a function in a new library class in a pre-existing module, ...
- [ ] Includes tests?
- **Tests** - Does the change include any explicit test code?
- Examples: Unit tests, integration tests, robot tests, ...
- [ ] Includes documentation?
- **Documentation** - Does the change contain explicit documentation additions
outside direct code modifications (and comments)?
- Examples: Update readme file, add feature readme file, link to documentation
on an a separate Web page, ...
## How This Was Tested
Verified pipeline artifacts are named as expected.
## Integration Instructions
This is considered a "breaking change" because artifacts are accessible via
ADO APIs and can be identified by the artifact name. While it is unlikely any
process is consuming these artifacts based on name, if they are, they will
need to use the new artifact naming convention introduced in this change.
Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com>
Michael Kubacki
dependabot[bot]
Project Mu UEFI Bot [bot]
Chasel Chiu
Taylor Beebe
Kuo, Ted