[Rebase & FF] Adding MM communication buffer validation

[kuqin12]

Description

This change adds a few validation before using the derived buffer size from message length.

However, note that the buffer size is not used directly due to a check after that. Thus the MM communication agent or the core in MM will not consume the value directly. But this would cause the MM handler to potentially receive a huge message in length.

• Impacts functionality?
• Impacts security?
• Breaking change?
• Includes tests?
• Includes documentation?

How This Was Tested

This is tested on QEMU ARM Virt platform and booted to Windows desktop.

Integration Instructions

N/A

[mu-automation]

❌ QEMU Validation Failed

Source Dependencies

Repository	Commit
mu_basecore	9a90186
mu_tiano_platforms	7e81e99

Results

Platform	Target	Build	Boot	Overall Boot Time	Build Logs	Boot Logs
Q35	DEBUG	❌ failure	⏩ skipped	N/A	Build Logs	N/A
ArmVirt	DEBUG	✅ success	✅ success	0m 14s	Build Logs	Boot Logs

Workflow run: https://github.com/microsoft/mu_basecore/actions/runs/31751859644

This comment was automatically generated by the Mu QEMU PR Validation workflow.

[Codecov Comments Bot (codecov-commenter)]

Codecov Report

❌ Patch coverage is 1.75439% with 56 lines in your changes missing coverage. Please review.
⚠️ Please upload report for BASE (release/202511@4fad4bc). Learn more about missing BASE report.

Files with missing lines	Patch %	Lines
...kg/Drivers/StandaloneMmIplPei/StandaloneMmIplPei.c	0.00%	55 Missing ⚠️
...kg/Drivers/MmCommunicationDxe/MmCommunicationDxe.c	50.00%	1 Missing ⚠️

Additional details and impacted files

@@               Coverage Diff                @@
##             release/202511   #1846   +/-   ##
================================================
  Coverage                  ?   0.50%           
================================================
  Files                     ?      30           
  Lines                     ?    5579           
  Branches                  ?      31           
================================================
  Hits                      ?      28           
  Misses                    ?    5551           
  Partials                  ?       0           

Flag	Coverage Δ
StandaloneMmPkg	0.50% <1.75%> (?)

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

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

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[kuqin12]

The platform validation is failed due to override hash failure.

[Michael Kubacki (makubacki)]

Given CommunicateHeader->MessageLength is UINT64:

typedef struct {
  ///
  /// Allows for disambiguation of the message format.
  ///
  EFI_GUID    HeaderGuid;
  ///
  /// Describes the size of Data (in bytes) and does not include the size of the header.
  ///
  // MU_CHANGE: BZ3398 Make MessageLength the same size in EFI_MM_COMMUNICATE_HEADER for both IA32 and X64.
  UINT64      MessageLength;
  ///
  /// Designates an array of bytes that is MessageLength in size.
  ///
  UINT8       Data[1];
} EFI_MM_COMMUNICATE_HEADER;

And BufferSize is UINT64:

typedef struct {
  ///
  /// Indicator GUID for MM core that the communication buffer is compliant with this v3 header.
  /// Must be gEfiMmCommunicateHeaderV3Guid.
  ///
  EFI_GUID    HeaderGuid;
  ///
  /// Describes the size of the entire buffer (in bytes) available for communication, including this communication header.
  ///
  UINT64      BufferSize;
  ///
  /// Reserved for future use.
  ///
  UINT64      Reserved;
  ///
  /// Allows for disambiguation of the message format.
  ///
  EFI_GUID    MessageGuid;
  ///
  /// Describes the size of MessageData (in bytes) and does not include the size of the header.
  ///
  UINT64      MessageSize;
  ///
  /// Designates an array of bytes that is MessageSize in size.
  ///
  UINT8       MessageData[];
} EFI_MM_COMMUNICATE_HEADER_V3;

Was there a reason not to use SafeUint64Add() (and in some similar places)?

[kuqin12]

I think this is rooted from the original PI spec defining MessageLength to be UINTN. And then a few other interfaces are cascaded with UINTN as the in/out argument type.

We can update the functions used here, and also update the local variables, but we will likely sprinkle a few (other) pointer castings here and there.

[Michael Kubacki (makubacki)]

The larger issue that comes to mind is truncation on a 32-bit machine where UINTN is 32-bit (which I don't think is a likely practical target except in the PEI modules). In any case, I think it should be as consistent as possible for the current types while making these types of validation correctness changes.

[kuqin12]

Agree with the concern. Part of the issue arise from the common communication routine between v1 and v3. If we separate them, some of the issues will be resolved, where v1 keeps using uintn while v3 uses only u64.

But I think for the case of these DXE phased modules, we have been using 64 bit as far as I am aware, so the UINTN and UINT64 are equivalent. The ARM modules are all UINT64 at this point.

So the only issue is in StandaloneMmIplPei, which does use 2 separate routines for v1 and v3 communicate. I will update the types there to match the native usage.