v2023020004.1.2

What's Changed

• DxePagingAudit: Skip Stack Publishing if Stack Info Isn't Valid @TaylorBeebe (#400)
  
  Change Details

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

  • 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
  

  
  

  ---

  
  

• [REBASE \&\& FF] FlatPageTableLib and DxePagingAuditTestApp Updates @TaylorBeebe (#395)
  
  Change Details

    ## Description

  This change set was primarily created to improve the accuracy of the DXE paging audit shell test. The problem was two-fold:

  1. The layout of memory would change as data was collected. This is solved by pre-allocating space for two of the memory maps (flat page table and EFI memory map). Those two maps will have their size requirement checked at the start of each function to ensure enough heap space has been allocated for them prior to populating them with memory information.
  2. The shell test was imprecise when reporting which regions failed the various tests. I'll use the UnallocatedMemoryIsRP() test as an example. The test parses the EFI memory map for EfiConventionalMemory regions which indicate unallocated memory. If any subsection of the region was not read protected, then the entire region would be reported as failing. With this update, every subsection which does not comply will be individually reported giving platform developers more precise information on where the problem areas are.

  Patch breakdown:

  1. Updates the DXE 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.
  2. Adds a function to FlatPageTableLib to dump the contents of a flat page table to the console. This is useful for debugging.
  3. Updates GetRegionAccessAttributes() in FlatPageTableLib 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.
  4. Updates the DXE paging audit shell tests to pre-allocate memory for memory maps. 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.
  5. Adds ValidatePageTableAttributes() to the DXE paging audit shell test logic. This function 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 and enables more precise reporting of regions which do not match the requirements.
  6. Updates the DXE paging audit shell tests to use ValidatePageTableAttributes() to determine policy compliance.

  How This Was Tested

  This was tested on Q35 and an ARM platform. Some changes in test caused the UnallocatedMemoryIsRP() test to erroneously fail due to reason 1 above which has been fixed with this patch set. Additionally, this patch set was checked by comparing the shell test output to the full HTML paging audit to verify that errant regions are exact and consistent.

  Integration Instructions

  N/A
  

  
  

  ---

  
  

🐛 Bug Fixes

• Fix DxePagingAuditTestApp Typo, Update FlatPageTableLib AARCH64 IsPageReadable() Check @TaylorBeebe (#402)
  
  Change Details

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

  • 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
  

  
  

  ---

  
  

Full Changelog: v2023020004.1.1...v2023020004.1.2