Releases: microsoft/mu_feature_dfci
v4.0.8
What's Changed
-
DfciPkg/DfciTests: remove silicon-specific test @cmruffin (#237)
Change Details
## Description
Current base tests DCFI_IntuneSettings use the Dfci3.ProcessorSMT.Enable option for testing DFCI V3 features but this is a silicon specific option that fails on Microsoft AARCH64 platforms as it is not present. Recommend the base tests avoid use of silicon-specific features as these tests will not broadly pass.
- Impacts functionality?
- Impacts security?
- Breaking change?
- Includes tests?
- Includes documentation?
- [ ]
How This Was Tested
DFCI testing on AARCH64 platform.
Integration Instructions
NA
Fixes #235
-
DfciPkg/DfciTests: fix refresh server pip failure @cmruffin (#236)
Change Details
## Description
Adds a command line switch to a pip command in the dockerfile. This allows the docker image creation process to pass.
--break-system-packages
was introduced in pip 23.0.1.-
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
Built on Windows 10.
Integration Instructions
N/A
Fixes #234
Full Changelog: v4.0.7...v4.0.8
v4.0.7
What's Changed
-
DfciPkg/DfciSettings.h: Add new DFCI settings @damonhunka (#240)
Change Details
## Description
Adding DFCI settings for two more power policies: After Power Loss, and Always on.
- After Power Loss will boot the device back to the previous state before power loss.
- Always on will always boot the device up to S0.
The difference between the behaviors of the two modes is
Always On
will boot it up even if power was yanked in the shutdown state.- Impacts functionality?
- Impacts security?
- Breaking change?
- Includes tests?
- Includes documentation?
Full Changelog: v4.0.6...v4.0.7
v4.0.6
What's Changed
-
Update DfciUpdate.c to avoid unsigned comparison checking greater than zero @spbrogan (#215)
Change Details
# Description
Resolve a CodeQL identified issue where an unsigned type was being checked against greater than or equal to zero. This will always be true and thus provides no value
- 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
Was not tested other than basic CI
Integration Instructions
NA
- Impacts functionality?
-
Fixes the Deprecation Warning for return in Robot Framework @Flickdm (#205)
Change Details
Description
Corrects deprecation warning in Robot Framework
For each item, place an "x" in between
[
and]
if true. Example:[x]
.
(you can also check items in the GitHub UI)- Impacts functionality?
- Impacts security?
- Breaking change?
- Includes tests?
- All tests were updated
- Includes documentation?
How This Was Tested
Ran before change - warnings
Ran after change - no warninsIntegration Instructions
N / A
🔐 Security Impacting
-
Update/tls ciphers @Flickdm (#206)
Change Details
# Preface
Description
This change limits the TLS Ciphers provided by the Docker Container to strictly the four TLSv1.2 Ciphers that Intune currently uses.
This will force firmware to OpenSSL TLSv1.2 and strictly the four algorithms currently supported
namely
cipher_list = [b'TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384', b'TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256', b'TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384', b'TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256']
For each item, place an "x" in between
[
and]
if true. Example:[x]
.
(you can also check items in the GitHub UI)-
[ ] Impacts functionality?
- Impacts security?
- Yes this will force the firmware to use the above mentioned ciphers
validation improvement, ...
- Yes this will force the firmware to use the above mentioned ciphers
- Breaking change?
- [] Includes tests?
- [] Includes documentation?
How This Was Tested
This nmap script can confirm the ssl siphers are what are expected
nmap --script ssl-enum-ciphers -p 443 127.0.0.1
Integration Instructions
N/A
-
📖 Documentation Updates
-
Update/tls ciphers @Flickdm (#206)
Change Details
# Preface
Description
This change limits the TLS Ciphers provided by the Docker Container to strictly the four TLSv1.2 Ciphers that Intune currently uses.
This will force firmware to OpenSSL TLSv1.2 and strictly the four algorithms currently supported
namely
cipher_list = [b'TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384', b'TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256', b'TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384', b'TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256']
For each item, place an "x" in between
[
and]
if true. Example:[x]
.
(you can also check items in the GitHub UI)-
[ ] Impacts functionality?
- Impacts security?
- Yes this will force the firmware to use the above mentioned ciphers
validation improvement, ...
- Yes this will force the firmware to use the above mentioned ciphers
- Breaking change?
- [] Includes tests?
- [] Includes documentation?
How This Was Tested
This nmap script can confirm the ssl siphers are what are expected
nmap --script ssl-enum-ciphers -p 443 127.0.0.1
Integration Instructions
N/A
-
Full Changelog: v4.0.5...v4.0.6
v4.0.5
What's Changed
-
Add StackCheckLib Instances to Platform DSC Files @TaylorBeebe (#202)
Change Details
## Description
An instance of StackCheckLib must be in each DSC to accommodate -fstack-protector and /GS flags.
- 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 in pipelines
Integration Instructions
N/A
- Impacts functionality?
-
remove edk2-basetools @Javagedes (#197)
Change Details
## Description
Removes edk2-basetools from pip-requirements.txt and any usage of it in the CISettings.py. The is done as there are changes in the build tools python source code that are available locally in BaseTools (as it is managed by Project Mu) that is not available in edk2-basetools.
- 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 the build system continues to use the local python source
Integration Instructions
N/A - only effects this repository's CI system.
- Impacts functionality?
Full Changelog: v4.0.4...v4.0.5
v4.0.4
What's Changed
-
Update pip-requirements.txt @Javagedes (#190)
Change Details
## Description
Updates edk2-pytool-extensions and edk2-pytool-library to work with the latest commit of MU_BASECORE
For each item, place an "x" in between
[
and]
if true. Example:[x]
.
(you can also check items in the GitHub UI)- 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
N/A
Integration Instructions
N/A
</blockquote> <hr> </details>
- Impacts functionality?
-
DfciPkg: Drop IntrinsicLib @makubacki (#185)
Change Details
## Description
Drop the library instance in the DSC due to recent refactor in
CryptoPkg in 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, ...
- 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
- DfciPkg build.
Integration Instructions
N/A - Only local package build is affected.
- Impacts functionality?
-
.git-blame-ignore-revs: Ignore Line Ending and Uncrustify only commits @makubacki (#182)
Change Details
## Description
Adds commits that only applied Uncrustify formatting or converted
line endings to a .git-blame-ignore-revs file so they are ignored
by git blame. This is supported by GitHub:
https://github.blog/changelog/2022-03-24-ignore-commits-in-the-blame-view-beta/This helps clean up git blame by filtering out these changes.
Note: This file needs to be updated on rebase branches. Processes
like filter-branch can automatically update relevant SHAs.- 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
git blame
Integration Instructions
N/A
- Impacts functionality?
-
Add missing library header guards @makubacki (#181)
Change Details
## Description
All header files should include header guards.
Some header files, such as those which define structures,
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.- 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
- Compilation
- CodeQL
Integration Instructions
N/A
- Impacts functionality?
Full Changelog: v4.0.3...v4.0.4
v4.0.3
What's Changed
🐛 Bug Fixes
-
Fix invalid access of NewRecoveryChallenge when memory allocation fails @Nishanth1311 (#168)
Change Details
## Description If memory allocation for the NewChallenge variable should not be used. It will result in Invalid access at the following line. NewChallenge->SerialNumber = 0;
With this change if memory allocation for the NewChallenge variable fails, EFI_OUT_OF_RESOURCES is returned
- Impacts functionality? No
- Impacts security? No
- Breaking change? No
- Includes tests? No
- Includes documentation? No
How This Was Tested
Build passes with this change
Integration Instructions
N/A
Full Changelog: v4.0.2...v4.0.3
v4.0.2
What's Changed
🔐 Security Impacting
-
Use New Stack Cookie Library @TaylorBeebe (#162)
Change Details
## Description
Update DFCI DSC file to use the new stack cookie library.
- 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: v4.0.1...v4.0.2
v4.0.1
What's Changed
-
ci.yaml: add PrEval entry @Javagedes (#122)
Change Details
## Description
Adds a PrEval entry to all ci.yaml files 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, ...
- 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
N/A
Integration Instructions
N/A
</blockquote> <hr> </details>
- Impacts functionality?
🐛 Bug Fixes
-
DfciV1SupportLibNull: Assign actual library class @makubacki (#127)
Change Details
## Description
The library class is currently
DfciSupportLib
in the INF file. This
name is not used anywhere else including consuming code and
documenation. Therefore, some packages have used the library class
name used elsewhere (DfciV1SupportLibNull
) but that may give a
warning since the library class does not match the INF.This changes updates the INF so the name is consistent.
There's also minor other cleanup:
-
Fix
BASE_NAME
so it accurately identifies the instance -
Move
MdePkg.dec
to the beginning of the package order to allow
more specific definitions to override generic ones inMdePkg
. -
Remove empty sections cluttering the file.
-
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
DfciPkg build and build of packages dependent on the library class.
Integration Instructions
If
DfciSupportLib
was being used before to reference this library class instance
in a package, update it toDfciV1SupportLib
.
-
Full Changelog: v4.0.0...v4.0.1
v4.0.0
What's Changed
-
Update pipeline builds for selfhosted Azure agents @kuqin12 (#103)
Change Details
# Preface
Please ensure you have read the contribution docs prior
to submitting the pull request. In particular,
pull request guidelines.Description
This change updated the mu_devops to use the Jobs/PrGate.yml pipeline and update synchronization files.
For each item, place an "x" in between
[
and]
if true. Example:[x]
.
(you can also check items in the GitHub UI)- 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 on selfhost-agents and existing agents.
Integration Instructions
Pipeline changes, N/A for integration.
</blockquote> <hr> </details>
- Impacts functionality?
-
Updated submodules to use their 202302 branches @kenlautner (#100)
Change Details
## Description
Update submodules to use their 202302 branches.
- 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
Pending
Integration Instructions
N/A
</blockquote> <hr> </details>
- Impacts functionality?
-
Allow all exceptions to indicate system is offline @mikeytdisco (#95)
Change Details
Pinging a QEMU virtual system doesn't work for detecting the system going offline, so the ping was removed from both the offline and online path of the test cases. However, this broke testing with real system.
Allow all exceptions to signal system not available when waiting for online or offline.
Fixes #94
- Impacts functionality?
- Impacts security?
- Includes tests?
- Includes documentation?
How This Was Tested
Tested on the QEMU path and a physical system.
Integration Instructions
N/A
</blockquote> <hr> </details>
⚠️ Breaking Changes
-
Change the source of the serial number to the Type1 BIOS information … @mikeytdisco (#78)
Change Details
…serial number
Description
A test exemption had to be added for an OEM that has a device with different Type1 and Type3 serial numbers.
Type1 is the system board, and Type3 is the enclosure or chassis. All laptops seen prior to this OEM had the same serial number for both Type1 and Type3. Fixes #77Potentially a breaking change for testing when a Device Under Test has different serial numbers for Type1 and Type3.
-
Impacts functionality?
-
Impacts security?
-
Breaking change?
-
Includes tests?
-
Includes documentation?
How This Was Tested
Tested with a fixed DfciDeviceIdSupportLib that used the Type1 SMBIOS serial number on a Windows DUT in a QemuQ35Pkg environment with different smbios serial numbers. The DfciDeviceIdSupportLib is a platform provided library.
Integration Instructions
N/A
</blockquote> <hr> </details>
-
📖 Documentation Updates
-
Update/readme cleanup @Flickdm (#97)
Change Details
# Preface
Please ensure you have read the contribution docs prior
to submitting the pull request. In particular,
pull request guidelines.Description
Updating documentation to include HTTP Connection definitions
For each item, place an "x" in between
[
and]
if true. Example:[x]
.
(you can also check items in the GitHub UI)- 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
<Please describe the test(s) that were run to verify the changes.>
Integration Instructions
<Describe how these changes should be integrated. Use N/A if nothing is required.>
</blockquote> <hr> </details>
- Impacts functionality?
Full Changelog: v3.0.0...v4.0.0
v3.0.0
What's Changed
⚠️ Breaking Changes
-
Dfci support for using a QemuQ35Pkg virtual system as the device under test @mikeytdisco (#84)
Change Details
## Description
Fixes #83.
This is all changes to the Dfci UnitTest and Docs directories. There is no change to DFCI functionality.
Quite a number of little changes needed to support Dfci in a QemuQ35Pkg virtual system. The Q35 environment has fewer settings, so there are fewer settings tested in the Enroll/Unenroll operations. Due to a pending restructure of the settings test, the current settings test will fail due to settings not in Q35. All the other tests have been tested.
The restart mechanism needed to be updated to not rely on ping. Since ping isn't forwarded to Q35, Q35 appeared to never go away.
DFCI_SupportLib.py needed a lot of changes to pass flake8.
This PR will need additional testing using a physical system.
-
Impacts functionality?
-
Impacts security?
-
Breaking change?
This PR will need additional testing using a physical system to ensure the new restart detections mechanism still works.
-
Includes tests?
-
Includes documentation?
How This Was Tested
Tested with a QemuQ35Pkg virtual system.
Integration Instructions
N/A
</blockquote> <hr> </details>
-
📖 Documentation Updates
-
Dfci support for using a QemuQ35Pkg virtual system as the device under test @mikeytdisco (#84)
Change Details
## Description
Fixes #83.
This is all changes to the Dfci UnitTest and Docs directories. There is no change to DFCI functionality.
Quite a number of little changes needed to support Dfci in a QemuQ35Pkg virtual system. The Q35 environment has fewer settings, so there are fewer settings tested in the Enroll/Unenroll operations. Due to a pending restructure of the settings test, the current settings test will fail due to settings not in Q35. All the other tests have been tested.
The restart mechanism needed to be updated to not rely on ping. Since ping isn't forwarded to Q35, Q35 appeared to never go away.
DFCI_SupportLib.py needed a lot of changes to pass flake8.
This PR will need additional testing using a physical system.
-
Impacts functionality?
-
Impacts security?
-
Breaking change?
This PR will need additional testing using a physical system to ensure the new restart detections mechanism still works.
-
Includes tests?
-
Includes documentation?
How This Was Tested
Tested with a QemuQ35Pkg virtual system.
Integration Instructions
N/A
</blockquote> <hr> </details>
-
Other Changes
-
pip: bump edk2-basetools from 0.1.44 to 0.1.45 @dependabot (#88)
Change Details
Bumps [edk2-basetools](https://github.com/tianocore/edk2-basetools) from 0.1.44 to 0.1.45.
Commits
- See full diff in compare view
You can trigger a rebase of this PR by commenting
@dependabot rebase
.
Dependabot commands and options
You can trigger Dependabot actions by commenting on this PR:
@dependabot rebase
will rebase this PR@dependabot recreate
will recreate this PR, overwriting any edits that have been made to it@dependabot merge
will merge this PR after your CI passes on it@dependabot squash and merge
will squash and merge this PR after your CI passes on it@dependabot cancel merge
will cancel a previously requested merge and block automerging@dependabot reopen
will reopen this PR if it is closed@dependabot close
will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually@dependabot ignore this major version
will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)@dependabot ignore this minor version
will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)@dependabot ignore this dependency
will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
-
pip: bump edk2-basetools from 0.1.43 to 0.1.44 @dependabot (#87)
Change Details
Bumps [edk2-basetools](https://github.com/tianocore/edk2-basetools) from 0.1.43 to 0.1.44.
Commits
- See full diff in compare view
You can trigger a rebase of this PR by commenting
@dependabot rebase
.
Dependabot commands and options
You can trigger Dependabot actions by commenting on this PR:
@dependabot rebase
will rebase this PR@dependabot recreate
will recreate this PR, overwriting any edits that have been made to it@dependabot merge
will merge this PR after your CI passes on it@dependabot squash and merge
will squash and merge this PR after your CI passes on it@dependabot cancel merge
will cancel a previously requested merge and block automerging@dependabot reopen
will reopen this PR if it is closed@dependabot close
will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually@dependabot ignore this major version
will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)@dependabot ignore this minor version
will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)@dependabot ignore this dependency
will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
-
pip: bump edk2-pytool-extensions from 0.22.2 to 0.23.0 @dependabot (#85)
Change Details
Bumps [edk2-pytool-extensions](https://github.com/tianocore/edk2-pytool-extensions) from 0.22.2 to 0.23.0.
Release notes
Sourced from edk2-pytool-extensions's releases.
v0.23.0
What's Changed
- repo_resolver: add git version Check by
@Javagedes
in tianocore/edk2-pytool-extensions#486 - Remove z flag for git worktree list porcelain by
@Javagedes
in tianocore/edk2-pytool-extensions#497 - repo_resolver.py:
repo_details()
to use first remote if origin does not exist by@Javagedes
in tianocore/edk2-pytool-extensions#490
Other Changes
- Update Ubuntu and git documentation by
@Javagedes
in tianocore/edk2-pytool-extensions#460 - Add edk2_setup tests by
@Javagedes
in tianocore/edk2-pytool-extensions#467
Breaking Changes
repo_resolver.repo_details()
will no longer support worktree paths that contain a newline character due to the removal of the-z
flag. This is to reduce the necessary git version for stuart tools to work.Full Changelog:...
- repo_resolver: add git version Check by