02 Feb 18:14

github-actions

7f821af

v2023020000.1.4

What's Changed

[CHERRY-PICK] [REBASE \& FF] Fix CodeQL Issues in AmlLib and PL061GPIO @os-d (#203)
Change Details
## Description
Both of these components failed a CodeQL check for comparing non-equal width types in a loop. This fixes the issue.

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, ...
- 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

Confirmed CI passed.

Integration Instructions

N/A.
```
  </blockquote>
  <hr>
</details>
```

Implement Memory Attribute Protocol Installation Policy Option @TaylorBeebe (#200)
Change Details
## Description
Linux shim currently incorrectly uses the UEFI memory attribute protocol
causing a fault. The broken shim does not have the NXCOMPAT
flag, so compatibility mode can be used to uninstall the protocol
when it is loaded. For flexibility, this patch implements the policy
configuration option to allow ARM platforms to choose not to install the
protocol.
- 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 SBSA by running the DxePagingAuditTestApp with the protocol policy set to TRUE and FALSE

Integration Instructions

N/A
```
  </blockquote>
  <hr>
</details>
```

.git-blame-ignore-revs: Ignore Line Ending and Uncrustify only commits @makubacki (#194)
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, ...
- 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

Full Changelog: v2023020000.1.3...v2023020000.1.4

Contributors

makubacki, os-d, and TaylorBeebe

Assets 2

17 Nov 22:33

github-actions

v2023020000.1.2

58e7430

v2023020000.1.2

What's Changed

ArmPkg/Drivers/CpuDxe: Cast table entry @makubacki (#178)
Change Details
## Description
Casts the table entry as a 32-bit integer since the value may be
larger than 32-bit. A cast is needed to prevent a compiler warning.
- 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
- ArmPkg build
- Virtual platform boot
Integration Instructions

N/A

Full Changelog: v2023020000.1.1...v2023020000.1.2

Contributors

makubacki

Assets 2

17 Nov 20:47

github-actions

v2023020000.1.1

f8bea42

v2023020000.1.1

What's Changed

🐛 Bug Fixes

Fix Some Visual Studio Issues [Rebase \& FF] @makubacki (#176)
Change Details
## Description
Two fixes to improve overall code and Visual Studio compatibility:

ArmPkg: Fix pointer type errors

The code tries to use a data pointer type for a function pointer and
Visual Studio doesn't like it.

Fixes this warning:
nonstandard extension, function/data pointer conversion in expression

This change represents the function pointer with the appropriate type
(instead of VOID*) and defines the type with a typedef for code
clarity.

A minor change is added to also validate function pointer parameters
in an already modified function to generally improve its robustness.

Some practices like adding a function description are not added
because the function prototype is from ArmMmuLib which doesn't
currently have function descriptions and adding them is outside the
scope of the compiler fix being added in this change.

ArmPkg/Drivers/CpuDxe: Check integer before conversion

GetNextEntryAttribute() assigns a 64-bit integer to 32-bit integers.
This change checks that the value fits in a 32-bit integer and
fixes the following Visual Studio compiler warning:

'=': conversion from 'UINT64' to 'UINT32', possible loss of data
- 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
- Visual Studio 2019/2022 build
Integration Instructions

No special work other than picking up the changes.

Full Changelog: v2023020000.1.0...v2023020000.1.1

Contributors

makubacki

Assets 2

19 Oct 00:49

github-actions

v2023020000.1.0

f594d42

v2023020000.1.0

What's Changed

🚀 Features & ✨ Enhancements

MemoryInitPei: Remove Non-RT Types from Mem Type Info HOB @makubacki (#168)
Change Details
## Description
MemoryInitPei: Remove Non-RT Types from Mem Type Info HOB

Removes the following types from the memory type information HOBs
produced in the MemoryInitPei modules in ArmPlatformPkg and ArmVirtPkg.
- EfiBootServicesCode
- EfiBootServicesData
- EfiLoaderCode
- EfiLoaderData
When the memory type information UEFI variable is updated in BDS,
it goes through the common variable check code attached to the UEFI
variable driver which explicitly checks the size of the variable data
to determine if the variable update is valid.

MemoryTypeInfoVarCheckHandler () in
MdeModulePkg/Library/MemoryTypeInfoSecVarCheckLib/MemoryTypeInfoSecVarCheckLib.c.

The size here is 0x50 instead of the expected size of 0x30. It
is not common to place non-runtime memory types in the memory type
information HOB so the types are removed from the HOB published
here to align with typical code expectations.

UEFI variable update error:
```
  ERROR: MemoryTypeInfoVarCheckHandler() - DataSize = 0x50 Expected = 0x30
  Variable Check handler fail Security Violation -
    4C19049F-4137-4DD3-9C10-8B97A83FFDFA:MemoryTypeInformation
  Memory Type Information settings cannot be saved. OS S4 may fail!
```
Some Arm platforms may use a different UEFI variable driver that does
not perform this check. If the types are truly needed, the variable
check code should be updated to compensate for them.
- 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
- ArmPlatformPkg build and CI
- ArmVirtPkg build and CI
- QemuSbsaPkg build and boot to EFI shell with test apps
Integration Instructions

Review code to determine if either of these PEIMs (MemoryInitPeim).
If so, whether code was dependent on the memory types in the memory
type information HOB that were removed to determine if further changes
are needed.

Full Changelog: v2023020000.0.7...v2023020000.1.0

Contributors

makubacki

Assets 2

11 Oct 15:37

github-actions

v2023020000.0.7

80cb4a2

v2023020000.0.7

What's Changed

Remove `MDEPKG_NDEBUG` from DynamicTables.dsc.inc @kuqin12 (#163)
Change Details
## Description
The current build option inserted from DynamicTables.dsc.inc making the release build debug prints to be completely muted. This is undesirable when platforms would like to keep logging capabilities, i.e. advanced logger.

This change removes the build option that inserted the macro definition and leave the option to platform consumers.
- 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 proprietary platforms that includes this file and confirmed release builds can print strings to serial port.

Integration Instructions

N/A
```
  </blockquote>
  <hr>
</details>
```

Full Changelog: v2023020000.0.6...v2023020000.0.7

Contributors

kuqin12

Assets 2

15 Aug 16:29

github-actions

v2023020000.0.6

97f99c2

v2023020000.0.6

What's Changed

[Cherry-Pick] ArmPkg: DefaultExceptionHandlerLib: Do Not Allocate Memory @os-d (#145)
Change Details
## Description
If gST->ConOut is available when Arm's DefaultExceptionHandler is running, AsciiPrint will get called to attempt to print to ConOut, in addition to the serial output.

AsciiPrint calls AsciiInternalPrint in UefiLibPrint.c which in turn calls AllocatePool to allocate a buffer to convert the Ascii input string to a Unicode string to pass to ConOut->OutputString.

Per the comment on DefaultExceptionHandler, we should not be allocating memory in the exception handler, as this can cause the exception handler to fail if we had a memory exception or the system state is such that we cannot allocate memory.

It has been observed on ArmVirtQemu that exceptions generated in the memory handling code will fail to output the stack dump and CPU state that is critical to debugging because the AllocatePool will fail.

This patch fixes the Arm and AARCH64 DefaultExceptionHandlers to not allocate memory when ConOut is available and instead use stack memory to convert the Ascii string needed for SerialPortWrite to the Unicode string needed for ConOut->OutputString. Correspondingly, ArmVirtQemu can now output the stack dump and CPU state when hitting an exception in memory code.

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, ...
- 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 ArmVirtQemu on edk2.

Integration Instructions

N/A.

Full Changelog: v2023020000.0.5...v2023020000.0.6

Contributors

os-d

Assets 2

28 Jul 23:58

github-actions

v2023020000.0.5

154d988

v2023020000.0.5

What's Changed

QemuVirtMemInfoPeiLib: Allow PcdSystemMemorySize to be non-fixed [Rebase \& FF] @makubacki (#143)
Change Details
## Description
Platforms today may use this PCD as a dynamic PCD as that is an
allowed type in its PCD declaration. From ArmPkg.dec:
```
[PcdsFixedAtBuild.common, PcdsDynamic.common, PcdsPatchableInModule.common]
  gArmTokenSpaceGuid.PcdSystemMemorySize|0|UINT64|0x0000002A
```
This library causes a build error if it used as a dynamic PCD since
it places the PCD in a [FixedPcd] section in the INF.

Other libraries do set the PCD and depend on the dynamic PCD behavior.

Since this library accesses the PCD with PcdGet64 () which is
compatible with FixedAtBuild PCDs, this change moves the PCD out of an
explicit [FixedPcd] section to resolve the following build error:
```
  INFO -  : error 3000: Building modules from source INFs, following
                        PCD use Dynamic and FixedAtBuild access method.
                        It must be corrected to use only one access
                        method.
  INFO -        gArmTokenSpaceGuid.PcdSystemMemorySize
```
- 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

CI build.

Integration Instructions

N/A

Full Changelog: v2023020000.0.4...v2023020000.0.5

Contributors

makubacki

Assets 2

28 Jun 14:07

github-actions

v2023020000.0.3

9f454bc

v2023020000.0.3

What's Changed

🐛 Bug Fixes

Update Arm Memory Attribute Protocol Logging @TaylorBeebe (#134)
Change Details
## Description
Fixes #129 and reformats the debug prints.
- 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

CI Pipelines

Integration Instructions

N/A
```
  </blockquote>
  <hr>
</details>
```

Full Changelog: v2023020000.0.2...v2023020000.0.3

Contributors

TaylorBeebe

Assets 2

Releases: microsoft/mu_silicon_arm_tiano

v2023020000.1.4

What's Changed

How This Was Tested

Integration Instructions

How This Was Tested

Integration Instructions

How This Was Tested

Integration Instructions

Contributors

v2023020000.1.3

What's Changed

Description

How This Was Tested

Integration Instructions

How This Was Tested

Integration Instructions

Contributors

v2023020000.1.2

What's Changed

How This Was Tested

Integration Instructions

Contributors

v2023020000.1.1

What's Changed

🐛 Bug Fixes

How This Was Tested

Integration Instructions

Contributors

v2023020000.1.0

What's Changed

🚀 Features & ✨ Enhancements

How This Was Tested

Integration Instructions

Contributors

v2023020000.0.7

What's Changed

How This Was Tested

Integration Instructions

Contributors

v2023020000.0.6

What's Changed

How This Was Tested

Integration Instructions

Contributors

v2023020000.0.5

What's Changed

How This Was Tested

Integration Instructions

Contributors

v2023020000.0.4

What's Changed

How This Was Tested

Integration Instructions

How This Was Tested

Integration Instructions

Contributors

v2023020000.0.3

What's Changed

🐛 Bug Fixes

How This Was Tested

Integration Instructions

Contributors