# 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
When allocating memory for a non-coherent DMA device, the current core
code removes the XP attribute, allowing code to execute from that
region. This is a security vulnerability and unneeded. This change
updates to mark the region as XP when allocating memory for the
non-coherent DMA device.
These allocations in this function are limited to `EfiBootServicesData`
and `EfiRuntimeServicesData`, which we expect to be XP.
This also updates a comment in PRM code that has a similar looking
pattern, but does not clear `EFI_MEMORY_XP` because it does not pass any
CPU arch attributes to the `SetMemorySpaceAttributes` which that
function interprets as a request to not clear any attributes.
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
Tested on QEMU and a physical platform.
## Integration Instructions
N/A.
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4389
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Jian J Wang <jian.j.wang@intel.com>
Signed-off-by: Chris Johnson <chris.n.johnson@intel.com>
Acked-by: Jiewen Yao <jiewen.yao@intel.com>
Reviewed-by: Oliver Smith-Denny <osde@linux.microsoft.com>
Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
(cherry picked from commit 0657e74116)
Description
Update the filters to suppress various CodeQL issues
- [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
N/A
Integration Instructions
N/A
Description
Update the filters to suppress various CodeQL issues
- [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
N/A
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
## 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
Additional CodeQL fixes for comparison between different integer
widths in loop comparisons.
Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com>
Adds a CodeQL filter file for this repo so the infrastructure is in
place for entries to be added in the future.
This will pick up filters from repos depended on like mu_basecore.
Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com>
## 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 SecurityPkg and boot changes on QemuQ35Pkg to EFI shell.
## Integration Instructions
N/A
## Description
Fix bitwidth issue
- [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
Building FmpDevicePkg
## 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 EmbeddedPkg.
## 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 SourceDkg and booting with changes on QemuQ35Pkg to EFI shell.
## Integration Instructions
N/A
## 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
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>
# 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
This change will remove the side effect of automatically setting the
setup mode to `CustomMode` after deleting PK. The usage of `CustomMode`
is largely avoided in the scope of Project Mu to reduce attack surfaces.
This change is to align with the original behavior provided through
`MsSecureBootLib`.
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?
- [x] Impacts security?
- [ ] Breaking change?
- [x] Includes tests?
- [ ] Includes documentation?
## How This Was Tested
Tested on Q35 virtual platform.
## 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
Updates the repo to match Tianocore requirements to use CRLF line
endings.
This allows this repo to pass CI against the latest mu_basecore.
- [ ] Impacts functionality?
- [ ] Impacts security?
- [ ] Breaking change?
- [ ] Includes tests?
- [ ] Includes documentation?
## How This Was Tested
Verified results with Line Ending Check CI plugin on Ubuntu.
## Integration Instructions
N/A
Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com>
## Description
Changes the matrix build job to be able to take input for the container
image used in the generic mu_devops file generated.
Will be used by: https://github.com/microsoft/mu_devops/pull/59
- [ ] Impacts functionality?
- [ ] Impacts security?
- [ ] Breaking change?
- [ ] Includes tests?
- [ ] Includes documentation?
## How This Was Tested
Tested on test pipeline with mu_devops changes made locally
## Integration Instructions
N/A
## Description
Adds an action to automatically sync labels used in this repository
from a centralized file in Project Mu DevOps.
https://github.com/microsoft/mu_devops
New labels should be added to the `Labels.yml` file in mu_devops.
Repo-specific labels are allowed to be defined. Those can either be
created in a repo-local config YAML file (preferred) or manually
in the "Labels" section of the repo.
- [ ] Breaking change?
- Will this change break pre-existing builds or functionality without
action being taken?
**No**
## How This Was Tested
On fork repositories.
## Integration Instructions
Now downstream integration required, only impacts this repo
Repo users should understand label definitions and read instructions
noted in this change regarding how to modify labels in the future.
Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com>
## Description
Enables stale bot to automatically closed old issues in this repo.
https://github.com/actions/stale
This action is largely based on a reusable workflow from Mu DevOps.
Current configuration:
- Stale PR: After 60 days
- Stale Issue: After 45 days
- Days until PR and Issue close: 7 days
- Exempt labels:
- `impact:security`
- `state:backlog`
- `state:under-discussion`
- Stale Issue label: `state:stale`
- Stale PR label: `state:stale`
- Comments are left when marked stale and when closed
These settings come directly from the default setting values in
the Mu DevOps reusable workflow.
Note: The `workflow_dispatch` trigger is added to allow the workflow to
be manually
invoked if ever needed.
- [ ] Breaking change?
- Will this change break pre-existing builds or functionality without
action being taken?
**No**
## How This Was Tested
- Verified workflow on mu_basecore fork.
- Example run:
https://github.com/makubacki/mu_basecore/actions/runs/3526648651
- Verified workflow in mu_basecore release/202208 branch
## Integration Instructions
N/A - Only affects the GitHub workflow in this repo
Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com>
## Description
Passing in access attributes to SetMemorySpaceAttributes() will cause
the existing attributes to be overwritten. The MMIO region should have
the appropriate attributes applied during memory protection
initialization and the attributes of the memory space descriptor are
inaccurate. Don't pass in any CPU arch attributes so SetMemorySpaceAttributes()
doesn't subsequently call gCpu->SetMemoryAttributes().
## Breaking change?
No
## How This Was Tested
- Booting to the OS and running the paging audit app on Q35
## Integration Instructions
N/A
Because VS2022 is now the recommended compiler for Project Mu, we need
to update the conditional for the stack cookie libraries.
Stack cookie support is hooked into our memory protection policy, so we
can utilize stack cookies on release builds.
No
Enabling stack cookies
N/A
Updates this repo to use mu_devops for Azure Pipeline definitions.
In order to centralize definitions and avoid build churn in individual
Mu repos,
some changes are made to allow build administrators to quickly adjust
settings:
- Toolchain, VM image, and architecture are controlled by build
administrators through centralized
variable groups
- CI triggers, CI schedules, and PR triggers are controlled by build
administrators within the
individual pipeline UI settings
- [ ] Breaking change?
- Will this change break pre-existing builds or functionality without
action being taken?
**No**
Verified in test pipelines.
N/A - No developer integration required
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: Doug Flick <dougflick@microsoft.com>
Co-authored-by: Kun Qin <kuqin@microsoft.com>
Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com>
Removes an extra argument from the debug macro.
- [ ] Breaking change?
- Will this change break pre-existing builds or functionality without action being taken?
**No**
Verified DebugMacroCheck and CI pass with the change.
N/A
Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com>
(cherry picked from commit b4036b52b1)
To keep pip dependencies up to date.
- [ ] Breaking change?
- Will this change break pre-existing builds or functionality without action being taken?
**No**
Confirmed file matches contents of the file working in other repos.
N/A - Only updates this repo
Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3966
This change updated the default value of TPM device subclass PCD to
`0x010E0000` in order to match the definition of EFI_PERIPHERAL_TPM
from PI specification.
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Jian J Wang <jian.j.wang@intel.com>
Cc: Qi Zhang <qi1.zhang@intel.com>
Cc: Rahul Kumar <rahul1.kumar@intel.com>
Signed-off-by: Kun Qin <kuqin12@gmail.com>
This change added unit test and enabled it from pipeline for the updated
SecureBootVariableLib.
The unit test covers all implemented interfaces and certain corner cases.
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Jian J Wang <jian.j.wang@intel.com>
Cc: Min Xu <min.m.xu@intel.com>
Signed-off-by: Kun Qin <kun.qin@microsoft.com>
This change updated the interfaces provided by SecureBootVariableLib.
The new additions provided interfaces to enroll single authenticated
variable from input, a helper function to query secure boot status,
enroll all secure boot variables from UefiSecureBoot.h defined data
structures, a as well as a routine that deletes all secure boot related
variables.
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Jian J Wang <jian.j.wang@intel.com>
Cc: Min Xu <min.m.xu@intel.com>
Signed-off-by: Kun Qin <kun.qin@microsoft.com>
This patch provides an abstracted interface for platform to implement PK
variable related protection interface, which is designed to be used when
PK variable is about to be changed by UEFI firmware.
This change also provided a variable policy based library implementation
to accomodate platforms that supports variable policy for variable
protections.
Cc: Jiewen Yao <jiewen.yao@intel.com> [jyao1]
Cc: Jian J Wang <jian.j.wang@intel.com> [jwang36]
Cc: Min Xu <min.m.xu@intel.com> [mxu9]
Signed-off-by: Kun Qin <kun.qin@microsoft.com>
Cherry-picked from mu_common_intel_min_platform release/202102 as Tcg was moved to mu_tiano_plus in subsequent releases.
Original PR message:
TPM update flows typically require Platform Auth and typically capsule processor runs in BDS, so deferring until ReadyToBoot in BOOT_ON_FLASH_UPDATE permits TPM capsule update to complete.
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2858
In V2: Fixed patch format and uncrustify cleanup
In V1: Add debug functionality to examine TPM extend operations
performed by BIOS and inspect the PCR 00 value prior to
any BIOS measurements.
Signed-off-by: Rodrigo Gonzalez del Cueto <rodrigo.gonzalez.del.cueto@intel.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Jian J Wang <jian.j.wang@intel.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
Note: this should be easy to squash if the ApplyUncrustify script
is run from a correctly-configured machine during the next integration.
If in doubt, use Linux
Adds a new library instance that abstracts implementation of Hash 2
cryptography services. This abstraction is primarily added as a
library to allow a platform to link the code that produces the UEFI
Hash 2 Service Binding protocol and Hash 2 protocol to a module that
already links against the cryptography functionality to reduce
overall platform size.
Joey Vagedes
Project Mu Uefibot
Oliver Smith-Denny
Chris Johnson
Taylor Beebe
Taylor Beebe
Michael Kubacki
kuqin12
Sean Brogan
Chris Fernald
Kenneth Lautner
Barrett Karstens
Kun Qin
Kun Qin
Rodrigo Gonzalez del Cueto
Bret Barkelew