v3.0.0
What's Changed
-
Align with DxeGenericIpmi to use PcdIpmiCommandTimeoutSeconds @MarcChen46 (#185)
Change Details
## Description
Align with DxeGenericIpmi to use PcdIpmiCommandTimeoutSeconds to control IPMI cmd timeout.
- 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, ...
- Security - Does the change have a direct security impact on an application,
- 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, ...
- Breaking change - Will anyone consuming this change experience a break
- 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, ...
- Documentation - Does the change contain explicit documentation additions
How This Was Tested
Verified build and the IPMI cmd timeout can be controlled by PcdIpmiCommandTimeoutSeconds in all phase.
Integration Instructions
The default PcdIpmiCommandTimeoutSeconds is still 5 second, Platform is flexible to configure it in DSC file to meet platform requirement.
</blockquote> <hr> </details> - Impacts functionality?
⚠️ Breaking Changes
-
Replace PlatformPowerRestorePolicyConfigurationLib with PlatformPowerRestorePolicy @shrugupt (#182)
Change Details
## Description
In IpmiPowerRestorePolicy module, replace PlatformPowerRestorePolicyConfigurationLib with PlatformPowerRestorePolicy policy. Now, the platform specific power restore configuration is read via. PlatformPowerRestorePolicy.PolicyValue instead of GetPowerRestorePolicy API. Default implementation of PlatformPowerRestorePolicy is provided which always returns "no change".
This simplifies interface to provide platform specific configuration for power restore and reduce the number of libraires.
- 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, ...
- Security - Does the change have a direct security impact on an application,
- 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, ...
- Breaking change - Will anyone consuming this change experience a break
- 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, ...
- Documentation - Does the change contain explicit documentation additions
How This Was Tested
This was tested with consumer build pipeline on proprietary platforms.
Integration Instructions
- Remove PlatformPowerRestorePolicyConfigurationLib library implementation in the platform code.
- Use PlatformPowerRestorePolicyDefault.inf or introduce platform code to produce PlatformPowerRestorePolicy policy.
- Impacts functionality?
🔐 Security Impacting
-
Use New Stack Cookie Library @TaylorBeebe (#184)
Change Details
## Description
MdePkg/MdeLibs.dsc.inc contains the definitions for the new stack cookie libraries.
- 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, ...
- Security - Does the change have a direct security impact on an application,
- 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, ...
- Breaking change - Will anyone consuming this change experience a break
- 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, ...
- Documentation - Does the change contain explicit documentation additions
How This Was Tested
Tested on Q35 GCC and MSVC builds
Integration Instructions
N/A
- Impacts functionality?
Full Changelog: v2.1.0...v3.0.0
