Update BootAuditTestApp to Correctly Test Load Option Variables #256
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
kuqin12
reviewed
Jun 5, 2023
kuqin12
approved these changes
Jun 5, 2023
UefiTestingPkg/AuditTests/BootAuditTest/UEFI/BootAuditTestApp.inf
Outdated
Show resolved
Hide resolved
makubacki
reviewed
Jun 5, 2023
UefiTestingPkg/AuditTests/BootAuditTest/UEFI/BootAuditTestApp.inf
Outdated
Show resolved
Hide resolved
makubacki
reviewed
Jun 5, 2023
UefiTestingPkg/AuditTests/BootAuditTest/UEFI/BootAuditTestApp.c
Outdated
Show resolved
Hide resolved
makubacki
reviewed
Jun 5, 2023
UefiTestingPkg/AuditTests/BootAuditTest/UEFI/BootAuditTestApp.c
Outdated
Show resolved
Hide resolved
makubacki
approved these changes
Jun 5, 2023
1 task
TaylorBeebe
added a commit
to TaylorBeebe/mu_plus
that referenced
this pull request
Jun 6, 2023
…osoft#256) ## Description BootAuditTestApp tests the variable policy for the SysPrep####, PlatformRecovery####, and Driver#### variables by attempting to get and set the variables. When calling SetVariable with one of these three variables, VarCheckLib will sanity check the variable data and return EFI_INVALID_PARAMETER if the data is not a valid load option. Because we want to check if the variables are writable, we need to create properly formatted data before calling SetVariable. This PR uses the DevicePath of the running EFI application to create a load option to properly test the writability of the boot option variables securely. Fixes Issue microsoft#252 - [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 Tested on Q35 ## Integration Instructions N/A
TaylorBeebe
added a commit
that referenced
this pull request
Jun 7, 2023
## Description BootAuditTestApp tests the variable policy for the SysPrep####, PlatformRecovery####, and Driver#### variables by attempting to get and set the variables. When calling SetVariable with one of these three variables, VarCheckLib will sanity check the variable data and return EFI_INVALID_PARAMETER if the data is not a valid load option. Because we want to check if the variables are writable, we need to create properly formatted data before calling SetVariable. This PR uses the DevicePath of the running EFI application to create a load option to properly test the writability of the boot option variables securely. Fixes Issue #252 - [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 Tested on Q35 ## Integration Instructions N/A
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description
BootAuditTestApp tests the variable policy for the SysPrep####, PlatformRecovery####, and Driver#### variables by attempting to get and set the variables. When calling SetVariable with one of these three variables, VarCheckLib will sanity check the variable data and return EFI_INVALID_PARAMETER if the data is not a valid load option. Because we want to check if the variables are writable, we need to create properly formatted data before calling SetVariable.
This PR uses the DevicePath of the running EFI application to create a load option to properly test the writability of the boot option variables securely.
Fixes Issue #252
flow, or firmware?
validation improvement, ...
in build or boot behavior?
a function in a new library class in a pre-existing module, ...
outside direct code modifications (and comments)?
on an a separate Web page, ...
How This Was Tested
Tested on Q35
Integration Instructions
N/A