v2023020004.1.1

What's Changed

• Add PeiCore method to find AdvancedLogger log buffer if LoggerInfo is… @apop5 (#389)
  
  Change Details

    ## 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)

  • 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

    </blockquote>
    <hr>
  </details>
  

Full Changelog: v2023020004.1.0...v2023020004.1.1