Release list

v2023020000.1.1

github-actions released this 17 Nov 20:47

v2023020000.1.1

f8bea42

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

v2023020000.1.0

github-actions released this 19 Oct 00:49

v2023020000.1.0

f594d42

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

v2023020000.0.7

github-actions released this 11 Oct 15:37

v2023020000.0.7

80cb4a2

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

v2023020000.0.6

github-actions released this 15 Aug 16:29

v2023020000.0.6

97f99c2

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

v2023020000.0.5

github-actions released this 28 Jul 23:58

v2023020000.0.5

154d988

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

v2023020000.0.3

github-actions released this 28 Jun 14:07

v2023020000.0.3

9f454bc

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

v2023020000.0.2

github-actions released this 27 Jun 00:37

v2023020000.0.2

bd7043d

What's Changed

🔐 Security Impacting

[CodeQL] DynamicTablesPkg: TableHelperLib: Fixing a mismatched variable size @kuqin12 (#135)
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 fixes a CodeQL issue in TableHelperLib.

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

This change was tested on ARM FVP platform.

Integration Instructions

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

Full Changelog: v2023020000.0.1...v2023020000.0.2

Contributors

kuqin12

Assets 2

v2023020000.0.1

github-actions released this 22 Jun 15:28

v2023020000.0.1

b5fa2e5

What's Changed

Improve Arm Memory Attribute Protocol Logging @os-d (#128)
Change Details
# Preface
Please ensure you have read the contribution docs prior
to submitting the pull request. In particular,
pull request guidelines.

Description

The Arm Memory Attribute Protocol logging is lacking, as evidenced by issue #124. This PR simply adds additional logging to make future debugging work easier and to help identify issue #124 in the wild, as it is likely to come up again with non-patched versions of the Linux shim.

The x86 Memory Attribute Protocol code already has good logging in the error cases.

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

Only logging update, no testing.

Integration Instructions

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

Onboarding ARM64 builds on selfhosted Azure pipeline agents @kuqin12 (#106)
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 added a few new matrix entries to support building mu_tiano_platforms on native ARM64 systems. The PR will cover both microsoft/mu_basecore#369 and microsoft/mu_basecore#305.

The PR should also be incorporated with mu_devops change.

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

This was tested on selfhost-agents and existing agents.

Integration Instructions

Pipeline changes, N/A for integration.
```
  </blockquote>
  <hr>
</details>
```

Full Changelog: v2023020000.0.0...v2023020000.0.1

Contributors

os-d and kuqin12

Assets 2

v2023020000.0.0

cfernald released this 26 May 18:19

v2023020000.0.0

52f542e

What's Changed

This is the first MU Silicon Arm Tiano 202302 release 🎉

The previous branch was 202208.

These versions correspond to edk2 stable release tags that the code is based upon.

Since edk2 makes a release every 3 months, two stable tags were actually picked up in this release:

Review those release notes to understand the changes coming in from edk2. In addition, Mu repos highlight important changes in their Readme files. Review the 202302 Readme before you move code to this branch to understand major changes.

Assets 2

Uh oh!

Releases: microsoft/mu_silicon_arm_tiano

Release list

v2023020000.1.1

What's Changed

🐛 Bug Fixes

How This Was Tested

Integration Instructions

Contributors

Uh oh!

v2023020000.1.0

What's Changed

🚀 Features & ✨ Enhancements

How This Was Tested

Integration Instructions

Contributors

Uh oh!

v2023020000.0.7

What's Changed

How This Was Tested

Integration Instructions

Contributors

Uh oh!

v2023020000.0.6

What's Changed

How This Was Tested

Integration Instructions

Contributors

Uh oh!

v2023020000.0.5

What's Changed

How This Was Tested

Integration Instructions

Contributors

Uh oh!

v2023020000.0.4

What's Changed

How This Was Tested

Integration Instructions

How This Was Tested

Integration Instructions

Contributors

Uh oh!

v2023020000.0.3

What's Changed

🐛 Bug Fixes

How This Was Tested

Integration Instructions

Contributors

Uh oh!

v2023020000.0.2

What's Changed

🔐 Security Impacting

Description

How This Was Tested

Integration Instructions

Contributors

Uh oh!

v2023020000.0.1

What's Changed

Description

How This Was Tested

Integration Instructions

Description

How This Was Tested

Integration Instructions

Contributors

Uh oh!

v2023020000.0.0

What's Changed

Uh oh!