Updated CISettings.py to use the edk2toolext codeql helpers #413
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
## Description This crate provides a rust wrapper around UEFI HII Keyboard Layout structures. The relevant structures defined in the UEFI spec are not well-suited for direct definition in rust; so this crate defines analogous rust structures and provides serialization/deserialization support for converting the rust structures into byte buffers and vice versa. This crate uses the `scroll` crate (https://github.com/m4b/scroll) to facilitate serialization/deserialization of the Hii structures. ## Examples and Usage Retrieving a default (en-US) layout, writing it to a buffer, and then reading the buffer back into a rust structure: ``` use hii_keyboard_layout::{get_default_keyboard_pkg, HiiKeyboardPkg}; use scroll::{Pread, Pwrite}; let mut buffer = [0u8; 4096]; let package = get_default_keyboard_pkg(); buffer.pwrite(&package, 0).unwrap(); let package2: HiiKeyboardPkg = buffer.pread(0).unwrap(); assert_eq!(package, package2); ``` - [x] Impacts functionality? - Introduces a new crate providing support for HII layouts. - [ ] Impacts security? - [ ] Breaking change? - [x] Includes tests? - Includes standard rust unit tests. - [x] Includes documentation? - Includes standard rust documentation. ## How This Was Tested Verified by included unit tests. ## Integration Instructions This crate requires the "scroll," "num-traits" and "num-drive" crates, so platforms intending to use it will need to add these as dependencies in their workspace Cargo.toml files. This PR does this for the workspace Cargo.toml that is at the root of mu_plus. Sample: ``` scroll = { version = "0.11", default-features = false, features = ["derive"]} num-traits = { version = "0.2", default-features = false} num-derive = { version = "0.4", default-features = false}
## Description
Adds a new library class (InputChannelLib) that allows the TPM replay
event log to be passed through a platform-specific mechanism.
- [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
- Passed FW CFG TPM event log through QemuQ35Pkg
- Verified library integrated without a custom log being passed uses
lower priority input channels as expected
- Verified BaseInputChannelLibNull is functionally usable for skipping
custom log input.
## Integration Instructions
Add
`InputChannelLib|TpmTestingPkg/Library/BaseInputChannelLibNull/BaseInputChannelLibNull.inf`
to a platform that uses the TPM Replay feature but does not provide a
custom input channel
instance.
Signed-off-by: Michael Kubacki <[email protected]>
…arameter (#349) synced local file(s) with [microsoft/mu_devops](https://github.com/microsoft/mu_devops). 🤖: View the [Repo File Sync Configuration File](https://github.com/microsoft/mu_devops/blob/main/.sync/Files.yml) to see how files are synced. --- This PR was created automatically by the [repo-file-sync-action](https://github.com/BetaHuhn/repo-file-sync-action) workflow run [#6774774926](https://github.com/microsoft/mu_devops/actions/runs/6774774926) Signed-off-by: Project Mu UEFI Bot <[email protected]>
## Description
Adds an instance of PanicLib that outputs through advanced logger
using AdvancedLoggerLib.
This allows platforms already using advanced logger to use this
library instance which can decrease the size impact as opposed to
linking to output stacks like serial that might be redundant when
advanced logger is active.
- [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, ...
- [x] 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
- Physical IA32/X64 platform with advanced logger used in PEI
---
Example of a test `PANIC()` placed in `ResetSystemPei` through this
library
instance:
```
PANIC [ResetSystemPei] d:\src\ws\MU_BASECORE\MdeModulePkg\Universal\ResetSystemPei\ResetSystem.c(110): Test panic
```
## Integration Instructions
Use this library instance if routing panic messages through advanced
logger
is preferred.
Signed-off-by: Michael Kubacki <[email protected]>
## Description
Adds HID keyboard support to UefiHidDxe input driver.
- [x] Impacts functionality?
- Adds keyboard support.
- [ ] Impacts security?
- [ ] Breaking change?
- [ ] Includes tests?
- [x] Includes documentation?
- standard rustdocs
## How This Was Tested
Tested with USB keyboard support in QEMU. Early iterations also tested
in hardware.
## Integration Instructions
Platforms will need to add `HiiKeyboardLayout = {path =
"HidPkg/Crates/HiiKeyboardLayout"}` to the `[workspace.dependencies]` in
their cargo.toml if not already present.
synced local file(s) with [microsoft/mu_devops](https://github.com/microsoft/mu_devops). 🤖: View the [Repo File Sync Configuration File](https://github.com/microsoft/mu_devops/blob/main/.sync/Files.yml) to see how files are synced. --- This PR was created automatically by the [repo-file-sync-action](https://github.com/BetaHuhn/repo-file-sync-action) workflow run [#6854437789](https://github.com/microsoft/mu_devops/actions/runs/6854437789) Signed-off-by: Project Mu UEFI Bot <[email protected]>
## Description
When using advanced logger starting from DxeCore, the library
constructor will allocate space for the advanced logger buffer.
When this allocation takes place, the associated global variable
`mMaxAddress` will be created to specify the last address for the log
buffer.
In the DxeCore case, the calculation for `mMaxAddress` did not take into
account the size of the `ADVANCED_LOGGER_INFO` structure that is at the
start of the buffer, resulting in an inconsistent address between
`mMaxAddress` and `LoggerInfo->LogBuffer + LoggerInfo->LogBufferSize`
All other instances of this code use `LoggerInfo->LogBuffer +
LoggerInfo->LogBufferSize`, so change DxeCore library instance to use
the same logic as other library instances.
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,
...
- [ ] 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
Found by setting debug messages to such a high level that the end of the
buffer was reached, resulting in incorrect checks of `mMaxAddress`
overwriting the end of the buffer.
Incorrect logic was tripped up in `ValidateInfoBlock()` where
`mMaxAddress` would cause a return of `false`, which in turn would
result in NULL being returned from an arbitrary call to
`AdvancedLoggerGetLoggerInfo`.
## Integration Instructions
n/a
## Description
This change adds an inspection of `mLoggerInfo` variable before reading
from GetTime() runtime service. As the advanced logger design expects
the `mLoggerInfo` to be set to NULL, we should always check the pointer
before usage, otherwise page fault could occur under certain edge cases.
- [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
This was tested on QEMU Q35 platform.
## Integration Instructions
N/A
---------
Co-authored-by: Michael Kubacki <[email protected]>
## Description Fix an issue where rust boot services allocator implementation could deadlock if memory allocations were attempted at different TPLs. Deadlock occurs in following scenario: 1. Task running at low TPL initiates an allocation request. 2. While that allocation is in progress and the lock is held, an interrupt occurs, and a new task executes at a higher TPL 3. new task attempts an allocation. Deadlock occurs because the higher TPL task cannot acquire the lock because it is held by the lower TPL task, and the lower TPL task cannot make forward progress because it has been interrupted by the higher TPL task. To resolve this, this PR updates the allocation implementation to remove the spinlock. An AtomicPtr is used to give well-ordered access to the bootservices pointer used as the basis for the allocation implementation. Other aspects of the implementation (i.e. creation of the allocation tracker) are already thread-safe or are the responsibility of the boot services implementation. PR also contains some minor style cleanup. - [ ] Impacts functionality? - [ ] Impacts security? - [ ] Breaking change? - [x] Includes tests? - RustBootServicesAllocatorDxe unit tests updated to accommodate new implementation. - [ ] Includes documentation? ## How This Was Tested Verified boot on QEMU. ## Integration Instructions N/A
## Description This PR resolves an issue where invocation of the debugln!() macro could result in deadlock due to contention between two different TPL levels. The deadlock occurs in the following scenario: 1. A task running at a lower TPL invokes debugln!() and acquires the spinlock on the logger object. 2. That task is interrupted by a TPL running at a higher level (the lower task has not released the lock). 3. The higher TPL invokes debugln!(). In this scenario, the higher TPL task cannot make forward progress because it cannot acquire the lock held by the lower TPL task, and the lower TPL task is not executing because it was interrupted by the higher TPL task. This resolves the issue by changing the "lock" to a "try_lock" - in the scenario above, this allows the higher TPL task to make forward progress. This has the downside of dropping the message from the higher TPL task; so this is only intended as an interim fix. - [ ] Impacts functionality? - [ ] Impacts security? - [ ] Breaking change? - [ ] Includes tests? - [ ] Includes documentation? ## How This Was Tested Reproduced the issue using QEMU emulator; with this change the above flow no longer deadlocks. ## Integration Instructions N/A
## Description USB HID specification 1.11 (https://www.usb.org/document-library/device-class-definition-hid-111) section 7.2.6 states: ``` When initialized, all devices default to report protocol. However the host should not make any assumptions about the device’s state and should set the desired protocol whenever initializing a device. ``` In testing actual devices, it has been observed that some actual endpoint HID devices come up in "boot protocol" rather than "report protocol." This PR implements the recommendation that the host (in this case, the UsbHidDxe driver) not make any assumptions about device state, and explicitly sets report protocol for devices that implement the "boot" interface subclass. The PR also makes a minor adjustment to debug verbosity. - [ ] Impacts functionality? - [ ] Impacts security? - [ ] Breaking change? - [ ] Includes tests? - [ ] Includes documentation? ## How This Was Tested Verified with QEMU that command is sent; verified with hardware that has this issue that SetProtocol resolves it. ## Integration Instructions N/A
Signed-off-by: Project Mu UEFI Bot <[email protected]>
## 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
EDK2 added EfiUnacceptedMemoryType to the memory type list. This update
adds this memory type to the memory protection test app and skips it
because it is not allocatable.
- [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 on Q35
## Integration Instructions
N/A
Allows TCG event logs with the "crypto agile format" to be decoded similar to those generated for TPM Replay by the script. This includes the log produced by Windows (usually present in the C:\Windows\Logs\MeasuredBoot directory). The log is passed with the existing log input parameter "-e". Example: TpmReplay.py -e WindowsLog.log -o YamlLog.yaml -l TxtLog.txt -v Signed-off-by: Michael Kubacki <[email protected]>
Adds the capability to recognize UEFI variable data in UEFI variable events (e.g. EV_EFI_VARIABLE_DRIVER_CONFIG) and output that to the YAML file and text log. This makes inspecting and configuring UEFI variables more user friendly. Signed-off-by: Michael Kubacki <[email protected]>
Add support for accepting SHA1 hashes. Signed-off-by: Michael Kubacki <[email protected]>
Uses a local logger instance to avoid using the root logger to avoid picking up log output from external libraries. Signed-off-by: Michael Kubacki <[email protected]>
Updates the string formatting for UEFI variable data to return a hexadecimal string followed by a decoded ASCII representation to make the data easier to view. This can be seen in a file specified using the `-l` parameter in combination with `-v` to output verbose text to the file. Signed-off-by: Michael Kubacki <[email protected]>
Describes crytpo agile event log and UEFI variable decode support. Signed-off-by: Michael Kubacki <[email protected]>
Bumps [edk2-pytool-library](https://github.com/tianocore/edk2-pytool-library) from 0.19.7 to 0.19.8. Signed-off-by: dependabot[bot] <[email protected]> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Updates the requirements on [mockall](https://github.com/asomers/mockall) to permit the latest version. Signed-off-by: dependabot[bot] <[email protected]> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
synced local file(s) with [microsoft/mu_devops](https://github.com/microsoft/mu_devops). 🤖: View the [Repo File Sync Configuration File](https://github.com/microsoft/mu_devops/blob/main/.sync/Files.yml) to see how files are synced. --- This PR was created automatically by the [repo-file-sync-action](https://github.com/BetaHuhn/repo-file-sync-action) workflow run [#7264686520](https://github.com/microsoft/mu_devops/actions/runs/7264686520) Signed-off-by: Project Mu UEFI Bot <[email protected]>
Bumps [edk2-pytool-extensions](https://github.com/tianocore/edk2-pytool-extensions) from 0.26.3 to 0.26.4. Signed-off-by: dependabot[bot] <[email protected]> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
#389) ## Description This was discovered in a platform that uses AdvancedLogger Starting in Pei, but without permanent memory until after MRC runs. (i.e. AdvancedLoggerLib PeiCore instance allocates CAR heap for the log buffer) The platform makes uses of EFI_PEI_TEMPORARY_RAM_DONE_PPI, where is tears down all variable range MTRRs. When PeiCore is reentered after memory has become available, it will relocate Hobs to system memory, then it will go through the Hobs and fix up the memory allocation pointers to point to the system memory addresses instead of the Heap addresses. During this transition, the PlatformBlob pointer will become invalid, after CAR is torn down. During the PeiCore's `PeiServicesInstallPpi (&mMemoryDiscoveredPpi);`, a debug message will attempt to be output about the `Install PPI: ` of the Memory Discovered Ppi, and the current logic will attempt to use the PlatformBlob, which results in a memory exception (the pointer is all Fs). This PR updates the logic in `AdvancedLoggerGetLoggerInfo` to verify the PlatformBlob pointer contains the correct signature before returning it, and if that fails, it then will go through Memory Allocation Hobs to try to find a memory allocation that corresponds to the AdvancedLogger buffer. If it fails, it will fall through to the existing functionality of creating a new allocation hob. 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, ... - [ ] 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 that the system that was triggering an exception was able to function correctly after this change was incorporated. ## Integration Instructions N/A
Bumps [regex](https://github.com/mrabarnett/mrab-regex) from 2023.10.3 to 2023.12.25. Signed-off-by: dependabot[bot] <[email protected]> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Description
This updates the paging audit to always write out all .dat files
even if the buffers are empty. The presence of the file acts
as a receipt that the audit was run successfully and helps with
automated unit testing.
- [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 on Q35 by creating the paging audit.
Integration Instructions
N/A
Description
This patch adds a function to dump the contents of a flat page
table to the console. This is useful for debugging.
- [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 on Q35 by running the function.
Integration Instructions
N/A
Description
GetRegionAccessAttributes() takes an input region description and page
table map and outputs the attributes of that region. Because it's
common for multi-page regions to have varying attributes, the patch
updates the function to return the attributes of the first
attribute-contiguous range found in the region and report the actual
size of that range. This allows the caller to collect the attributes
of the region by calling the function repeatedly instead of needing
to guess which subsection of the region has contiguous attributes.
- [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 on Q35 by running the function.
Integration Instructions
N/A
Description
The page table map, EFI memory map, and EFI memory space map all
describe the layout of the system address space. Because of this,
if allocations are performed while these maps are being generated,
then the maps generated the earliest will be inaccurate. This
change pre-allocates the memory for these maps before they are
generated to ensure that the maps are consistent.
- [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 on Q35 by running the app with the following patch.
Integration Instructions
N/A
…sAttributes()
Description
ValidatePageTableAttributes() is a function that validates the attributes
of the input memory region. It uses GetRegionAccessAttributes() to get
the attributes of the region and compares them to the
attributes passed in. This function will be used by each test case
to check that the page/translation table attributes match the memory
protection requirements.
- [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 on Q35 by running the app with the following patch.
Integration Instructions
N/A
Description
This patch updates the shell tests to use the validate function from
the previous patch. This allows the tests to be more exact in reporting
regions which do not meet the memory protection security bar.
- [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 on Q35 by running the app.
Integration Instructions
N/A
Updates the requirements on [scroll](https://github.com/m4b/scroll) to permit the latest version. Signed-off-by: dependabot[bot] <[email protected]> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
## Description
The MemoryInfoDatabase.dat file contains information about the content
of memory regions. If an entry in the database file is invalid, it will
break the generation of the paging audit. Before adding the stack info
to the database file, check that the stack size is greater than zero.
- [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 on Q35 by generating the paging audit
## Integration Instructions
N/A
…eReadable() Check (#402) ## Description DxePagingAuditTestApp: When checking an image section characteristics, a bitmasking is done which incorrectly includes a logical OR instead of a bitwise OR. FlatPageTableLib: The AARCH64 IsPageReadable() routine correctly checks for the no access, r/w case (0b00) but not the r/w, r/w case (0b01) because both 0b11 and 0b01 would pass the latter check. - [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 on a Surface ARM platform and SBSA ## Integration Instructions N/A
## Description f535499 split the MemoryProtectionTestApp into DXE and SMM instances but did not delete the old files to give consumers time to update their platform DSC files. This PR is the breaking change which removes the old files. - [ ] 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 N/A ## 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 This change introduces a new message entry structure, which contains extra information of log producer and can be used to differentiate the different boot phases, i.e. PEI, DXE, SMM, etc. Platforms that have multiple firmware entities can leverage this extra information to distinguish coalesced memory logging regions. The updated applications (UEFI shell app and host OS Python script) are also updated to support new message entry structure while maintaining the backwards compatibility. Resolves #375. 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, ... - [ ] 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, ... - [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 This change was tested on QEMU Q35 and verified that prefix are properly injected for DXE phase prints. ## Integration Instructions The log parsers are updated, thus platforms use the existing parser should pick up the latest tool from mu_plus. For platforms that carry their own implementation, they should add the proper support in their own implementation before picking up this change from mu_plus.
#404) ## 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, ... - [ ] 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 - `git blame` ## Integration Instructions N/A Signed-off-by: Michael Kubacki <[email protected]>
## Description 267e27f change introduced a build error on certain platforms, due to a local variable being used uninitialized. This change will set the variable to 0 before usage. - [ ] 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 This change is tested with LineParserTestApp on QEMU Q35 platform. ## Integration Instructions N/A
Bumps [edk2-pytool-library](https://github.com/tianocore/edk2-pytool-library) from 0.19.8 to 0.19.9. Signed-off-by: dependabot[bot] <[email protected]> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
## Description
The advanced logging at runtime is lack of usage. However, this becomes
increasingly important for server platforms, where the system could
potentially stay up for months, or even years. This will make the
advanced logger fill up the buffer during runtime/MM logging well ahead
of a reset event, making the buffer content stale when being reviewed.
This change added a feature PCD guarded feature that, when enabled, will
automatically wrap the LogCurrent cursor to the beginning and continue
to log. This will effectively create a circular buffer as the stale
content will remain in place. The tooling update is still under
development.
- [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
This was tested on QEMU Q35 along with the UEFI shell based test app to
verify that the entry after wrapping is correct and is multi-threading
safe.
## Integration Instructions
Platforms can enable this feature by setting
`gAdvLoggerPkgTokenSpaceGuid.PcdAdvancedLoggerAutoClearEnable|TRUE`
…hanges associated with that
github-actions
bot
added
language:python
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## release/202302 #413 +/- ##
================================================
Coverage ? 8.55%
================================================
Files ? 110
Lines ? 18571
Branches ? 1363
================================================
Hits ? 1588
Misses ? 16489
Partials ? 494
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. |
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
The 202311 rebase moved the codeql plugin from .pytool to Basetools. This requires a change in CISettings.py to reference the correct codeql helper functions. Instead of using the internal versions we instead move to the edk2 pytool extensions version.
For each item, place an "x" in between
[and]if true. Example:[x].(you can also check items in the GitHub UI)
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 with CI.
Integration Instructions
N/A