Update Memory Protection Special Region Logic to Handle Edge Case

[TaylorBeebe]

Description

The special region functionality enables platforms to describe what the memory attributes should be for any number of memory regions when the memory protection initialization routine is complete. The logic which ensures that the special regions are accounted for has a case which is unhandled and described below:

Thef following is a special region which says that the address range should have EFI_MEMORY_RP:
0x4000-0x8000, EFI_MEMORY_RP

When generating the memory map used as a blueprint for applying attributes to the platform, there can be some gaps. Take the following example:
0x0000-0x6000,
0x7000-0x8000

The logic before would properly apply the attributes to the region 0x4000-0x6000 but would get confused when there is a gap between the last map entry and next map entry when the special region covers both. This change fixes this issue by checking if the special region start is within the map entry interval OR the map entry start is within the special region interval (a proper overlap 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 Q35 and a Surface ARM platform by publishing a special region which encounters the edge case.

Integration Instructions

N/A

[codecov-commenter]

Codecov Report

Attention: 2 lines in your changes are missing coverage. Please review.

Comparison is base (0ad607f) 1.87% compared to head (9f1ab37) 1.87%.

Files	Patch %	Lines
...eModulePkg/Core/Dxe/Misc/MemoryProtectionSupport.c	0.00%	2 Missing ⚠️

Additional details and impacted files

@@               Coverage Diff               @@
##           release/202302     #665   +/-   ##
===============================================
  Coverage            1.87%    1.87%           
===============================================
  Files                1341     1341           
  Lines              286451   286451           
  Branches             5765     5765           
===============================================
  Hits                 5359     5359           
  Misses             281042   281042           
  Partials               50       50           

Flag	Coverage Δ
MdeModulePkg	0.72% <0.00%> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[os-d]

I walked through the code a bit, I think this is covered, but just to confirm, if the special region were to cover a range that terminated in a gap in the memory map, this would still work? I.e. if 0x0000-0x2000 and 0x6000 - 0x9000 were the memory map descriptors and the special region was 0x1000 - 0x4000, this would not cause an issue?

[TaylorBeebe]

I walked through the code a bit, I think this is covered, but just to confirm, if the special region were to cover a range that terminated in a gap in the memory map, this would still work? I.e. if 0x0000-0x2000 and 0x6000 - 0x9000 were the memory map descriptors and the special region was 0x1000 - 0x4000, this would not cause an issue?

It will work in that it will only update what's in the memory map. So, it would update intervals 0x1000-0x2000 but would essentially ignore the 0x2000-0x4000 interval. If a memory range is not in the map at this point, it's because it is nonexistent in the GCD memory map (which usually means that it is unmapped in the page table). Skipping nonexistent regions was done to accommodate some of our platforms which hit errors when applying attributes to upper address regions. The correct thing to do MAY be to always update the special region intervals regardless of if the region is mapped at this point. I can also see an argument in the other direction.