## Description
An instance of StackCheckLib must be in each DSC to accommodate
-fstack-protector and /GS flags.
- [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
Tested in pipelines
## Integration Instructions
N/A
MsWheaReportHandlerPei() is passed to ReportHwErrRecRouter() for the
MS_WHEA_ERR_REPORT_PS_FN value where that is defined as:
typedef
EFI_STATUS
(EFIAPI *MS_WHEA_ERR_REPORT_PS_FN)(
IN MS_WHEA_ERROR_ENTRY_MD *MsWheaEntryMD
);
So, MsWheaReportHandlerPei() needs to include EFIAPI as well.
Similarly, MsWheaRscHandlerPei() needs EFIAPI due to the definition
of EFI_PEI_RSC_HANDLER_CALLBACK.
Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com>
fixup
Removes an unnecessary condition since unsigned values are always
greater than or equal to 0.
Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com>
Removes `MsWheaCMOSStoreClearAll()` which is scoped to the file and
not used. Improves code readability and maintenance.
Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com>
Some header files, such as those which define structures or classes,
cannot be included more than once within a translation unit, as doing
so would cause a redefinition error. Such headers must be guarded to
prevent ill-effects from multiple inclusion. Similarly, if header
files include other header files, and this inclusion graph contains
a cycle, then at least one file within the cycle must contain header
guards in order to break the cycle. Because of cases like these, all
headers should be guarded as a matter of good practice, even if they
do not strictly need to be.
Furthermore, most modern compilers contain optimizations which are
triggered by header guards. If the header guard strictly conforms
to the pattern that compilers expect, then inclusions of that
header other than the first have absolutely no effect: the file
isn't re-read from disk, nor is it re-tokenised or re-preprocessed.
This can result in a noticeable, albeit minor, improvement to
compilation time.
Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com>
## Description
Update one DSC file to use the new stack cookie library, and
MdePkg/MdeLibs.dsc.inc contains the definitions for the new stack cookie
libraries for the remaining DSC files.
- [x] Impacts functionality?
- **Functionality** - Does the change ultimately impact how firmware
functions?
- Examples: Add a new library, publish a new PPI, update an algorithm,
...
- [x] 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
Tested on Q35 GCC and MSVC builds
## Integration Instructions
N/A
## Description
Fixed some CodeQL failures we're seeing in a variety of packages.
- [ ] Impacts functionality?
- **Functionality** - Does the change ultimately impact how firmware
functions?
- Examples: Add a new library, publish a new PPI, update an algorithm,
...
- [x] 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
Tested through CodeQL checks.
## Integration Instructions
N/A
## Description
Adds PrEval entries for all packages to enable the new PrEval Policy 5.
- [ ] 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
## Integration Instructions
N/A
## Description
UT_LOG functionality requires the unit tests to be running backed by the
unit test engine. Update the UT_LOG in the entry point to a debug
statement.
- [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
Running test on SBSA
## Integration Instructions
N/A
Description
Block some tests in the MsWheaEarlyStorageUnitTestApp behind a check
to the size of the early storage. This change is to prevent the test
from failing on platforms that do not have enough early storage to
accommodate the required early storage 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, ...
- [x] 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
Running the MsWheaEarlyUnitTestApp on Q35
Integration Instructions
N/A
Description
The checksum calculation for the MS Whea Early Storage could be invalid
if the size defined in the early storage PCD value is larger than the
early storage region capacity. To make the calculation more robust, the
checksum calculation is updated to read the actual bytes of the early
store instead of relying on an input buffer which may not have been
properly written to the early store. Without this change, the stored
WHEA records would be invalidated if the early storage PCD value is
too large.
- [x] Impacts functionality?
- **Functionality** - Does the change ultimately impact how firmware
functions?
- Examples: Add a new library, publish a new PPI, update an algorithm,
...
- [x] 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
Running the MsWheaEarlyUnitTestApp on Q35
Integration Instructions
N/A
Description
As MsWheaEarlyStorageLib is written, PcdMsWheaReportEarlyStorageCapacity
must include the offset of the MS WHEA early storage region. This
expectation is unintuitive and can lead to configuration errors and
underflow in MsWheaEarlyStorageGetMaxSize(). Instead of changing the
PCD to not include the offset (and consequentially force existing
platforms to update) this change checks that the PCD is at least as
large as the offset and ASSERTs if not. This change also updates
MsWheaESGetMaxDataCount() to avoid underflow if the ES region is smaller
than the header size.
- [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, ...
- [x] 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
Running the MsWheaEarlyUnitTestApp on Q35
Integration Instructions
N/A
## Description
Various fixes
- [x] Impacts functionality?
- **Functionality** - Does the change ultimately impact how firmware
functions?
- Examples: Add a new library, publish a new PPI, update an algorithm,
...
- [x] 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
Build and boot changes on QemuQ35Pkg to EFI shell.
## Integration Instructions
N/A
# Preface
Please ensure you have read the [contribution
docs](https://github.com/microsoft/mu/blob/master/CONTRIBUTING.md) prior
to submitting the pull request. In particular,
[pull request
guidelines](https://github.com/microsoft/mu/blob/master/CONTRIBUTING.md#pull-request-best-practices).
## Description
Fixing potential NULL pointer dereferences after allocation.
There is also an error involving variable comparison between different
width.
For each item, place an "x" in between `[` and `]` if true. Example:
`[x]`.
_(you can also check items in the GitHub UI)_
- [x] Impacts functionality?
- **Functionality** - Does the change ultimately impact how firmware
functions?
- Examples: Add a new library, publish a new PPI, update an algorithm,
...
- [x] 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 on Q35 virtual platform.
## Integration Instructions
N/A
---------
Co-authored-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
## Description
Current implement will allow extra variables with names specified under
`PcdBertEntriesVariableNames` and namespace GUID being
`gEfiHardwareErrorVariableGuid` to be collected into BERT table for OS
consumption.
However, variables under `gEfiHardwareErrorVariableGuid` has certain
restrictions that does not allow random variable names to be used and
could potentially clash with `HwErrRec####` occupied by other firmware
entities.
This change will add the flexibility for the platform to specify their
own
variable GUID to be collected during boot for BERT table usage.
For each item, place an "x" in between `[` and `]` if true. Example:
`[x]`.
_(you can also check items in the GitHub UI)_
- [x] Impacts functionality?
- [ ] Impacts security?
- [ ] Breaking change?
- [ ] Includes tests?
- [ ] Includes documentation?
## How This Was Tested
Tested on QEMU virtual systems and proprietary physical devices.
## Integration Instructions
For platforms that need to support specific CPER formatted variables
coalition into the BERT table, one should override the PCD value of
`gMsWheaPkgTokenSpaceGuid.PcdBertEntriesVariableGuid` of their choices.
Otherwise, `gEfiHardwareErrorVariableGuid` will be the default value and
certain variable naming schema might restrict the specific use case.
Because VS2022 is now the recommended compiler for Project Mu, we need
to update the conditional for the stack cookie libraries.
No
Enabling stack cookies
N/A
Include Stack Cookie Support Libs on Release Builds (#89)
Stack cookie support is hooked into our memory protection policy, so we
can utilize stack cookies on release builds.
No
Enabling Stack Cookies on Q35
N/A
Converts line endings in the following packages:
* AdvLoggerPkg: Fix line endings (LF to CRLF)
* DfciPkg: Fix line endings (LF to CRLF)
* HidPkg: Fix line endings (LF to CRLF)
* MfciPkg: Fix line endings (LF to CRLF)
* MsCorePkg: Fix line endings (LF to CRLF)
* MsGraphicsPkg: Fix line endings (LF to CRLF)
* MsWheaPkg: Fix line endings (LF to CRLF)
* PcBdsPkg: Fix line endings (LF to CRLF)
* UefiTestingPkg: Fix line endings (LF to CRLF)
* XmlSupportPkg: Fix line endings (LF to CRLF)
* ZeroTouchPkg: Fix line endings (LF to CRLF)
(cherry picked from commit a6195ca in release/202202)
Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com>
## Description
Resolves CodeQL issues.
Another lighter pass of CodeQL will occur shortly in the future.
- [ ] Breaking change?
- Will this change break pre-existing builds or functionality without action being taken?
**No**
## How This Was Tested
- Verified CI build
- Checked before and after CodeQL results
- Verified boot on QemuQ35Pkg
## Integration Instructions
N/A - If CodeQL was run before these changes, run again to get latest results
Co-authored-by: Ken Lautner <klautner@microsoft.com>
Co-authored-by: Mike Turner <miketur@microsoft.com>
Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com>
## Description
Builds upon the changes done in 5ce890ef to fix additional DEBUG
macro errors found in this repo.
- [ ] Breaking change?
- Will this change break pre-existing builds or functionality without action being taken?
**No**
## How This Was Tested
Verified repo package results with DebugMacroCheck as of the version
checked into mu_basecore at c4183eff.
## Integration Instructions
None - This is done to prepare for DebugMacroCheck integration in this repo.
Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com>
##Description
* Initialize BertVars to NULL for Milos platform build requirements.
##How this was tested
* Boot tested on Milos platform; UEFI build passes.
This change defined a new PCD `PcdBertEntriesVariableNames` for platform to define any wild card variables they would like to populate in a BERT table.
Note that the content for this variable must be compliant with CPER format. And the expected variables should be stored under `gEfiHardwareErrorVariableGuid`.
This PR cleaned GetRecordID function interface and added common definitions for easier use.
It added routine to apply variable policy on size and attributes for "RecordID". The lock is not applied as it might be changed on demand when logging a new telemetry entry.
(cherry picked from commit 34de8198f9)
Adds the MsWheaESAddRecordV0() function which finds a slot in early storage for a V0 type entry, adds it, and updates the header checksum and active range.
Also moves two defines from the early storage common header to MsWheaEarlyStorageLib.h.
These changes were made to accommodate use cases in the MM supervisor and MemoryProtectionExceptionHandlerLib.
Related work items: #2409
Update the menu to:
- Install gHwhMenuFormsetGuid so the menu properly displays if it is built
- Update the hex dump code to properly capture ASCII formatted bytes
- Went ahead and updated formatting while I was at it. It should now conform to edk2 standards
Move to the ES library header the definition for two structures used by the early storage logic to store records prior to var write availability, and move a few functions to the ES library. This is needed to write directly to the ES CMOS region in the correct format without using the RSC logic. Using RSC when in an exception context fails, but writing a report directly to CMOS and rebooting is effective.
Introduce Standalone MM version of WHEA report driver:
1. Replace all gSmst references with gMmst;
1. Added driver instance for WHEA Standalone MM type;
1. Abstract driver entrypoints for traditional and standalone MM instances;
1. Used SMM FTW protocol as depex for Standalone MM driver (since it requires the FVB in SMM to persist errors);
ReportStatusCode() is not currently working due to how the ReportDispatcher() in ReportStatusCodeRuntimeDxe.c handles the case where EFI_STATUS_CODE_DATA was not passed from the caller.
Currently, ReportDispatcher() creates and zeros EFI_STATUS_CODE_DATA before signaling the event that a HwErrRec is being created. This causes the optional data argument to be non NULL when reaching our router and, because the data is zeroed and therefore does not contain the proper guid, the entire record is thrown out.
This update sidesteps the nonissue where the creation of a hardware error record through reportstatuscode() triggers a reclaim when the common variable space is full.
Change WHEA meta data pointer to be EFI_PHYSICAL_ADDRESS to avoid bitwidth mismatch:
Pointer bit width in each architecture is defined as UINTN.
For hobs created in PEI phase, the ExtraSection type will be initialized in 32 bit environment. But when it is consumed in DXE phase, the upper 32 bit was left uninitialized and accessing it could result in GP fault.
The fix is to change the data type to EFI_PHYISICAL_ADDRESS to resolve data size change across 32-bit and 64-bit operations.
Add helper lib support to pack extra, unstructured data at the end of a telemetry event.
Add WheaReport functionality to identify the extra data and store it in an extra CPER section.
Also, add a bunch of tests for all of that stuff.
Taylor Beebe
Michael Kubacki
kenlautner
Joey Vagedes
Taylor Beebe
kuqin12
Antaeus Kleinert-Strand
Kun Qin
Barrett Karstens
Sean Brogan
Mike Turner
Bret Barkelew
Bret Barkelew
Matthew Carlson
Dmitry Antipov