-
Notifications
You must be signed in to change notification settings - Fork 2.9k
Support Standalone MM on OVMF #10961
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
b5a6d9e
to
54b4995
Compare
⚠ WARNING: Cannot add some reviewers: A user specified as a reviewer for this PR is not a collaborator of the repository. Please add them as a collaborator to the repository so they can be requested in the future. Non-collaborators requested: Attn Admins: Admin Instructions:
|
Can you explain why this is a good idea? |
From an x64 platform standpoint, Standalone MM is regarded as a better model compared to traditional MM, offering cleaner isolation in resource accessibility and reducing attack surfaces. With the growing shift towards Standalone MM-based solutions over SMM on x64 platforms, there is an increasing demand for a public platform to showcase the functionality of the Standalone MM framework on x64 systems. Additionally, this Standalone MM-based platform serves as a validation mechanism to ensure that Standalone MM-related changes operate as expected during check-in. |
055b330
to
7f4f7c1
Compare
PR can not be merged due to conflict. Please rebase and resubmit |
StandaloneMmPkg/Drivers/StandaloneMmIplPei/StandaloneMmIplPei.c
Outdated
Show resolved
Hide resolved
StandaloneMmPkg/Drivers/StandaloneMmIplPei/StandaloneMmIplPei.c
Outdated
Show resolved
Hide resolved
There could be scenarios where the HOB producer does not create any HOBs. In such cases, the buffer intended to be freed will have zero pages. This update addresses the issue that could cause assertions during runtime by ensuring that buffers with zero pages are not freed. Signed-off-by: Kun Qin <kun.qin@microsoft.com>
Current MM IPL in PEI phase does not open the MMRAM regions through MM access PPI. This is causing some platforms like OVMF reading all `0xFF`s when trying to relocate the Standalone MM core. This change opens all the MMRAM regions provided by MM access PPI and closes + locks the regions after initial MM foundation setup, when MM Access PPI is available. Platforms that require MM access PPI can inject depex through libraries. Signed-off-by: Kun Qin <kun.qin@microsoft.com>
This change extends the supported types to Standalone MM and Standalone MM Core module types to support potential MM usage. Signed-off-by: Kun Qin <kun.qin@microsoft.com>
This change extends the library to support MM_CORE_STANDALONE and MM_STANDALONE for usage in MM standalone environment. Signed-off-by: Kun Qin <kun.qin@microsoft.com>
This change extends the library to support MM_CORE_STANDALONE and MM_STANDALONE for usage in MM standalone environment. Signed-off-by: Kun Qin <kun.qin@microsoft.com>
This change extends the library to support MM_CORE_STANDALONE and MM_STANDALONE for usage in MM standalone environment. Signed-off-by: Kun Qin <kun.qin@microsoft.com>
This update refactors the existing SmmCpuFeaturesLib to eliminate direct calls to SMM-specific functions. In particular, the constructor has been relocated to traditional MM- specific C files, utilizing a common entry point. Furthermore, several implementation-specific functions have been modularized into its respective C files. These changes lay the groundwork for supporting a Standalone MM-based solution in the future. Signed-off-by: Kun Qin <kun.qin@microsoft.com>
…Ovmf This change adds the implementation of SmmCpuFeaturesLib for Ovmf to operate with Standalone MM supported platforms. Signed-off-by: Kun Qin <kun.qin@microsoft.com>
This change adds a PEIM that produces gEfiPeiMmControlPpiGuid to be used in PEI phase, i.e. boot strap MM foundation. This flow is largely in assemblence of MM control DXE driver and used the `SmiFeatures.*` files from the DXE drivers as the common resources. Signed-off-by: Kun Qin <kun.qin@microsoft.com>
This change adds a build time PCD to prevent the SmmControl2Dxe driver from re-initialization the MM related registers. This register is to be used when MmControlPei is already executed in PEI phase and completed setting up the MM control registers. Signed-off-by: Kun Qin <kun.qin@microsoft.com>
This update refactors QemuFlashFvbServicesRuntimeDxe to abstract out direct calls to SMM and DXE specific functions. Specifically, dynamic PCD usage and gBS references have been moved to SMM specific files. The constructor functionality has been relocated to a common implementation and is invoked from their respective entry points. These changes lay the groundwork for supporting a Standalone MM-based solution in the future. Signed-off-by: Kun Qin <kun.qin@microsoft.com>
This update introduces the implementation of QemuFlashFvbServices to support operation with Standalone MM backed platforms. Signed-off-by: Kun Qin <kun.qin@microsoft.com>
This change introduces a Null instance of MemEncryptSevLib to enable platforms that do not have confidential compute support. Signed-off-by: Kun Qin <kun.qin@microsoft.com>
… Stmm This change introduces a platform specific HOB producor library to meet the expectation of Standalone MM core. Signed-off-by: Kun Qin <kun.qin@microsoft.com>
This change adds a build flag in the platform DSC file to support standalone MM build on OVMF platform. The new standalone MM platform will not support S3 boot and thus no SMM lock box related components are included. Signed-off-by: Kun Qin <kun.qin@microsoft.com>
This change expands the CI pipeline build to a new platform type with Standalone MM support to ensure the incoming change works with Standalone MM environment on x64 platforms. Signed-off-by: Kun Qin <kun.qin@microsoft.com>
This update introduces a new section in the README file, detailing the design considerations of the recently onboarded Standalone MM platform in OVMF. The section is intended for future reference and should be revised accordingly if updates to the Standalone MM framework render these limitations obsolete. Signed-off-by: Kun Qin <kun.qin@microsoft.com>
Description
Standalone MM on x64 platforms is treated as a better model compared to traditional MM, offering cleaner isolation in resource accessibility and reducing attack surfaces. With the growing shift towards Standalone MM-based solutions over SMM on x64 platforms, there is an increasing demand for a public platform to showcase the functionality of the Standalone MM framework on x64 systems.
This change adds the support for booting OVMF with Standalone MM. It can be used as a validation mechanism to ensure that Standalone MM-related changes operate as expected during check-in.
The base of the new platform is OvmfX64 as the EDK2 solution for x86 based Standalone MM only supports x64.
How This Was Tested
This was tested with OVMF packge and booted to UEFI shell.
Integration Instructions
N/A