StandaloneMmPkg/Core: Implementation of Standalone MM Core Module.
Management Mode (MM) is a generic term used to describe a secure
execution environment provided by the CPU and related silicon that is
entered when the CPU detects a MMI. For x86 systems, this can be
implemented with System Management Mode (SMM). For ARM systems, this can
be implemented with TrustZone (TZ).
A MMI can be a CPU instruction or interrupt. Upon detection of a MMI, a
CPU will jump to the MM Entry Point and save some portion of its state
(the "save state") such that execution can be resumed.
The MMI can be generated synchronously by software or asynchronously by
a hardware event. Each MMI source can be detected, cleared and disabled.
Some systems provide for special memory (Management Mode RAM or MMRAM)
which is set aside for software running in MM. Usually the MMRAM is
hidden during normal CPU execution, but this is not required. Usually,
after MMRAM is hidden it cannot be exposed until the next system reset.
The MM Core Interface Specification describes three pieces of the PI
Management Mode architecture:
1. MM Dispatch
During DXE, the DXE Foundation works with the MM Foundation to
schedule MM drivers for execution in the discovered firmware volumes.
2. MM Initialization
MM related code opens MMRAM, creates the MMRAM memory map, and
launches the MM Foundation, which provides the necessary services to
launch MM-related drivers. Then, sometime before boot, MMRAM is
closed and locked. This piece may be completed during the
SEC, PEI or DXE phases.
3. MMI Management
When an MMI generated, the MM environment is created and then the MMI
sources are detected and MMI handlers called.
This patch implements the MM Core.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Sughosh Ganu <sughosh.ganu@arm.com>
Signed-off-by: Supreeth Venkatesh <supreeth.venkatesh@arm.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
2018-07-13 17:05:27 +02:00
|
|
|
/** @file
|
|
|
|
MM Core Main Entry Point
|
|
|
|
|
|
|
|
Copyright (c) 2009 - 2014, Intel Corporation. All rights reserved.<BR>
|
2020-12-03 13:30:25 +01:00
|
|
|
Copyright (c) 2016 - 2021, Arm Limited. All rights reserved.<BR>
|
2019-04-04 01:07:12 +02:00
|
|
|
SPDX-License-Identifier: BSD-2-Clause-Patent
|
StandaloneMmPkg/Core: Implementation of Standalone MM Core Module.
Management Mode (MM) is a generic term used to describe a secure
execution environment provided by the CPU and related silicon that is
entered when the CPU detects a MMI. For x86 systems, this can be
implemented with System Management Mode (SMM). For ARM systems, this can
be implemented with TrustZone (TZ).
A MMI can be a CPU instruction or interrupt. Upon detection of a MMI, a
CPU will jump to the MM Entry Point and save some portion of its state
(the "save state") such that execution can be resumed.
The MMI can be generated synchronously by software or asynchronously by
a hardware event. Each MMI source can be detected, cleared and disabled.
Some systems provide for special memory (Management Mode RAM or MMRAM)
which is set aside for software running in MM. Usually the MMRAM is
hidden during normal CPU execution, but this is not required. Usually,
after MMRAM is hidden it cannot be exposed until the next system reset.
The MM Core Interface Specification describes three pieces of the PI
Management Mode architecture:
1. MM Dispatch
During DXE, the DXE Foundation works with the MM Foundation to
schedule MM drivers for execution in the discovered firmware volumes.
2. MM Initialization
MM related code opens MMRAM, creates the MMRAM memory map, and
launches the MM Foundation, which provides the necessary services to
launch MM-related drivers. Then, sometime before boot, MMRAM is
closed and locked. This piece may be completed during the
SEC, PEI or DXE phases.
3. MMI Management
When an MMI generated, the MM environment is created and then the MMI
sources are detected and MMI handlers called.
This patch implements the MM Core.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Sughosh Ganu <sughosh.ganu@arm.com>
Signed-off-by: Supreeth Venkatesh <supreeth.venkatesh@arm.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
2018-07-13 17:05:27 +02:00
|
|
|
|
|
|
|
**/
|
|
|
|
|
|
|
|
#include "StandaloneMmCore.h"
|
|
|
|
|
|
|
|
EFI_STATUS
|
|
|
|
MmDispatcher (
|
|
|
|
VOID
|
|
|
|
);
|
|
|
|
|
|
|
|
//
|
|
|
|
// Globals used to initialize the protocol
|
|
|
|
//
|
|
|
|
EFI_HANDLE mMmCpuHandle = NULL;
|
|
|
|
|
|
|
|
//
|
|
|
|
// MM Core global variable for MM System Table. Only accessed as a physical structure in MMRAM.
|
|
|
|
//
|
|
|
|
EFI_MM_SYSTEM_TABLE gMmCoreMmst = {
|
|
|
|
// The table header for the MMST.
|
|
|
|
{
|
|
|
|
MM_MMST_SIGNATURE,
|
|
|
|
EFI_MM_SYSTEM_TABLE_REVISION,
|
|
|
|
sizeof (gMmCoreMmst.Hdr)
|
|
|
|
},
|
|
|
|
// MmFirmwareVendor
|
|
|
|
NULL,
|
|
|
|
// MmFirmwareRevision
|
|
|
|
0,
|
|
|
|
// MmInstallConfigurationTable
|
|
|
|
MmInstallConfigurationTable,
|
|
|
|
// I/O Service
|
|
|
|
{
|
|
|
|
{
|
|
|
|
(EFI_MM_CPU_IO)MmEfiNotAvailableYetArg5, // MmMemRead
|
|
|
|
(EFI_MM_CPU_IO)MmEfiNotAvailableYetArg5 // MmMemWrite
|
|
|
|
},
|
|
|
|
{
|
|
|
|
(EFI_MM_CPU_IO)MmEfiNotAvailableYetArg5, // MmIoRead
|
|
|
|
(EFI_MM_CPU_IO)MmEfiNotAvailableYetArg5 // MmIoWrite
|
|
|
|
}
|
|
|
|
},
|
|
|
|
// Runtime memory services
|
|
|
|
MmAllocatePool,
|
|
|
|
MmFreePool,
|
|
|
|
MmAllocatePages,
|
|
|
|
MmFreePages,
|
|
|
|
// MP service
|
|
|
|
NULL, // MmStartupThisAp
|
|
|
|
0, // CurrentlyExecutingCpu
|
|
|
|
0, // NumberOfCpus
|
|
|
|
NULL, // CpuSaveStateSize
|
|
|
|
NULL, // CpuSaveState
|
|
|
|
0, // NumberOfTableEntries
|
|
|
|
NULL, // MmConfigurationTable
|
|
|
|
MmInstallProtocolInterface,
|
|
|
|
MmUninstallProtocolInterface,
|
|
|
|
MmHandleProtocol,
|
|
|
|
MmRegisterProtocolNotify,
|
|
|
|
MmLocateHandle,
|
|
|
|
MmLocateProtocol,
|
|
|
|
MmiManage,
|
|
|
|
MmiHandlerRegister,
|
|
|
|
MmiHandlerUnRegister
|
|
|
|
};
|
|
|
|
|
|
|
|
//
|
|
|
|
// Table of MMI Handlers that are registered by the MM Core when it is initialized
|
|
|
|
//
|
|
|
|
MM_CORE_MMI_HANDLERS mMmCoreMmiHandlers[] = {
|
2024-05-13 20:11:22 +02:00
|
|
|
{ MmDriverDispatchHandler, &gEventMmDispatchGuid, NULL, FALSE },
|
StandaloneMmPkg/Core: Implementation of Standalone MM Core Module.
Management Mode (MM) is a generic term used to describe a secure
execution environment provided by the CPU and related silicon that is
entered when the CPU detects a MMI. For x86 systems, this can be
implemented with System Management Mode (SMM). For ARM systems, this can
be implemented with TrustZone (TZ).
A MMI can be a CPU instruction or interrupt. Upon detection of a MMI, a
CPU will jump to the MM Entry Point and save some portion of its state
(the "save state") such that execution can be resumed.
The MMI can be generated synchronously by software or asynchronously by
a hardware event. Each MMI source can be detected, cleared and disabled.
Some systems provide for special memory (Management Mode RAM or MMRAM)
which is set aside for software running in MM. Usually the MMRAM is
hidden during normal CPU execution, but this is not required. Usually,
after MMRAM is hidden it cannot be exposed until the next system reset.
The MM Core Interface Specification describes three pieces of the PI
Management Mode architecture:
1. MM Dispatch
During DXE, the DXE Foundation works with the MM Foundation to
schedule MM drivers for execution in the discovered firmware volumes.
2. MM Initialization
MM related code opens MMRAM, creates the MMRAM memory map, and
launches the MM Foundation, which provides the necessary services to
launch MM-related drivers. Then, sometime before boot, MMRAM is
closed and locked. This piece may be completed during the
SEC, PEI or DXE phases.
3. MMI Management
When an MMI generated, the MM environment is created and then the MMI
sources are detected and MMI handlers called.
This patch implements the MM Core.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Sughosh Ganu <sughosh.ganu@arm.com>
Signed-off-by: Supreeth Venkatesh <supreeth.venkatesh@arm.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
2018-07-13 17:05:27 +02:00
|
|
|
{ MmReadyToLockHandler, &gEfiDxeMmReadyToLockProtocolGuid, NULL, TRUE },
|
2024-05-14 04:20:06 +02:00
|
|
|
{ MmEndOfPeiHandler, &gEfiMmEndOfPeiProtocol, NULL, FALSE },
|
StandaloneMmPkg/Core: Implementation of Standalone MM Core Module.
Management Mode (MM) is a generic term used to describe a secure
execution environment provided by the CPU and related silicon that is
entered when the CPU detects a MMI. For x86 systems, this can be
implemented with System Management Mode (SMM). For ARM systems, this can
be implemented with TrustZone (TZ).
A MMI can be a CPU instruction or interrupt. Upon detection of a MMI, a
CPU will jump to the MM Entry Point and save some portion of its state
(the "save state") such that execution can be resumed.
The MMI can be generated synchronously by software or asynchronously by
a hardware event. Each MMI source can be detected, cleared and disabled.
Some systems provide for special memory (Management Mode RAM or MMRAM)
which is set aside for software running in MM. Usually the MMRAM is
hidden during normal CPU execution, but this is not required. Usually,
after MMRAM is hidden it cannot be exposed until the next system reset.
The MM Core Interface Specification describes three pieces of the PI
Management Mode architecture:
1. MM Dispatch
During DXE, the DXE Foundation works with the MM Foundation to
schedule MM drivers for execution in the discovered firmware volumes.
2. MM Initialization
MM related code opens MMRAM, creates the MMRAM memory map, and
launches the MM Foundation, which provides the necessary services to
launch MM-related drivers. Then, sometime before boot, MMRAM is
closed and locked. This piece may be completed during the
SEC, PEI or DXE phases.
3. MMI Management
When an MMI generated, the MM environment is created and then the MMI
sources are detected and MMI handlers called.
This patch implements the MM Core.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Sughosh Ganu <sughosh.ganu@arm.com>
Signed-off-by: Supreeth Venkatesh <supreeth.venkatesh@arm.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
2018-07-13 17:05:27 +02:00
|
|
|
{ MmEndOfDxeHandler, &gEfiEndOfDxeEventGroupGuid, NULL, FALSE },
|
|
|
|
{ MmExitBootServiceHandler, &gEfiEventExitBootServicesGuid, NULL, FALSE },
|
|
|
|
{ MmReadyToBootHandler, &gEfiEventReadyToBootGuid, NULL, FALSE },
|
|
|
|
{ NULL, NULL, NULL, FALSE },
|
|
|
|
};
|
|
|
|
|
2024-10-21 04:13:54 +02:00
|
|
|
BOOLEAN mMmEntryPointRegistered = FALSE;
|
|
|
|
MM_COMM_BUFFER *mMmCommunicationBuffer;
|
|
|
|
VOID *mInternalCommBufferCopy;
|
|
|
|
EFI_FIRMWARE_VOLUME_HEADER *mBfv = NULL;
|
StandaloneMmPkg/Core: Implementation of Standalone MM Core Module.
Management Mode (MM) is a generic term used to describe a secure
execution environment provided by the CPU and related silicon that is
entered when the CPU detects a MMI. For x86 systems, this can be
implemented with System Management Mode (SMM). For ARM systems, this can
be implemented with TrustZone (TZ).
A MMI can be a CPU instruction or interrupt. Upon detection of a MMI, a
CPU will jump to the MM Entry Point and save some portion of its state
(the "save state") such that execution can be resumed.
The MMI can be generated synchronously by software or asynchronously by
a hardware event. Each MMI source can be detected, cleared and disabled.
Some systems provide for special memory (Management Mode RAM or MMRAM)
which is set aside for software running in MM. Usually the MMRAM is
hidden during normal CPU execution, but this is not required. Usually,
after MMRAM is hidden it cannot be exposed until the next system reset.
The MM Core Interface Specification describes three pieces of the PI
Management Mode architecture:
1. MM Dispatch
During DXE, the DXE Foundation works with the MM Foundation to
schedule MM drivers for execution in the discovered firmware volumes.
2. MM Initialization
MM related code opens MMRAM, creates the MMRAM memory map, and
launches the MM Foundation, which provides the necessary services to
launch MM-related drivers. Then, sometime before boot, MMRAM is
closed and locked. This piece may be completed during the
SEC, PEI or DXE phases.
3. MMI Management
When an MMI generated, the MM environment is created and then the MMI
sources are detected and MMI handlers called.
This patch implements the MM Core.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Sughosh Ganu <sughosh.ganu@arm.com>
Signed-off-by: Supreeth Venkatesh <supreeth.venkatesh@arm.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
2018-07-13 17:05:27 +02:00
|
|
|
|
|
|
|
/**
|
|
|
|
Place holder function until all the MM System Table Service are available.
|
|
|
|
|
|
|
|
Note: This function is only used by MMRAM invocation. It is never used by DXE invocation.
|
|
|
|
|
|
|
|
@param Arg1 Undefined
|
|
|
|
@param Arg2 Undefined
|
|
|
|
@param Arg3 Undefined
|
|
|
|
@param Arg4 Undefined
|
|
|
|
@param Arg5 Undefined
|
|
|
|
|
|
|
|
@return EFI_NOT_AVAILABLE_YET
|
|
|
|
|
|
|
|
**/
|
|
|
|
EFI_STATUS
|
|
|
|
EFIAPI
|
|
|
|
MmEfiNotAvailableYetArg5 (
|
|
|
|
UINTN Arg1,
|
|
|
|
UINTN Arg2,
|
|
|
|
UINTN Arg3,
|
|
|
|
UINTN Arg4,
|
|
|
|
UINTN Arg5
|
|
|
|
)
|
|
|
|
{
|
|
|
|
//
|
|
|
|
// This function should never be executed. If it does, then the architectural protocols
|
|
|
|
// have not been designed correctly.
|
|
|
|
//
|
|
|
|
return EFI_NOT_AVAILABLE_YET;
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
Software MMI handler that is called when a ExitBoot Service event is signaled.
|
|
|
|
|
|
|
|
@param DispatchHandle The unique handle assigned to this handler by MmiHandlerRegister().
|
|
|
|
@param Context Points to an optional handler context which was specified when the handler was registered.
|
|
|
|
@param CommBuffer A pointer to a collection of data in memory that will
|
|
|
|
be conveyed from a non-MM environment into an MM environment.
|
|
|
|
@param CommBufferSize The size of the CommBuffer.
|
|
|
|
|
|
|
|
@return Status Code
|
|
|
|
|
|
|
|
**/
|
|
|
|
EFI_STATUS
|
|
|
|
EFIAPI
|
|
|
|
MmExitBootServiceHandler (
|
|
|
|
IN EFI_HANDLE DispatchHandle,
|
2021-12-03 03:00:59 +01:00
|
|
|
IN CONST VOID *Context OPTIONAL,
|
|
|
|
IN OUT VOID *CommBuffer OPTIONAL,
|
StandaloneMmPkg/Core: Implementation of Standalone MM Core Module.
Management Mode (MM) is a generic term used to describe a secure
execution environment provided by the CPU and related silicon that is
entered when the CPU detects a MMI. For x86 systems, this can be
implemented with System Management Mode (SMM). For ARM systems, this can
be implemented with TrustZone (TZ).
A MMI can be a CPU instruction or interrupt. Upon detection of a MMI, a
CPU will jump to the MM Entry Point and save some portion of its state
(the "save state") such that execution can be resumed.
The MMI can be generated synchronously by software or asynchronously by
a hardware event. Each MMI source can be detected, cleared and disabled.
Some systems provide for special memory (Management Mode RAM or MMRAM)
which is set aside for software running in MM. Usually the MMRAM is
hidden during normal CPU execution, but this is not required. Usually,
after MMRAM is hidden it cannot be exposed until the next system reset.
The MM Core Interface Specification describes three pieces of the PI
Management Mode architecture:
1. MM Dispatch
During DXE, the DXE Foundation works with the MM Foundation to
schedule MM drivers for execution in the discovered firmware volumes.
2. MM Initialization
MM related code opens MMRAM, creates the MMRAM memory map, and
launches the MM Foundation, which provides the necessary services to
launch MM-related drivers. Then, sometime before boot, MMRAM is
closed and locked. This piece may be completed during the
SEC, PEI or DXE phases.
3. MMI Management
When an MMI generated, the MM environment is created and then the MMI
sources are detected and MMI handlers called.
This patch implements the MM Core.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Sughosh Ganu <sughosh.ganu@arm.com>
Signed-off-by: Supreeth Venkatesh <supreeth.venkatesh@arm.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
2018-07-13 17:05:27 +02:00
|
|
|
IN OUT UINTN *CommBufferSize OPTIONAL
|
|
|
|
)
|
|
|
|
{
|
|
|
|
EFI_HANDLE MmHandle;
|
2020-12-03 21:52:01 +01:00
|
|
|
EFI_STATUS Status;
|
StandaloneMmPkg/Core: Implementation of Standalone MM Core Module.
Management Mode (MM) is a generic term used to describe a secure
execution environment provided by the CPU and related silicon that is
entered when the CPU detects a MMI. For x86 systems, this can be
implemented with System Management Mode (SMM). For ARM systems, this can
be implemented with TrustZone (TZ).
A MMI can be a CPU instruction or interrupt. Upon detection of a MMI, a
CPU will jump to the MM Entry Point and save some portion of its state
(the "save state") such that execution can be resumed.
The MMI can be generated synchronously by software or asynchronously by
a hardware event. Each MMI source can be detected, cleared and disabled.
Some systems provide for special memory (Management Mode RAM or MMRAM)
which is set aside for software running in MM. Usually the MMRAM is
hidden during normal CPU execution, but this is not required. Usually,
after MMRAM is hidden it cannot be exposed until the next system reset.
The MM Core Interface Specification describes three pieces of the PI
Management Mode architecture:
1. MM Dispatch
During DXE, the DXE Foundation works with the MM Foundation to
schedule MM drivers for execution in the discovered firmware volumes.
2. MM Initialization
MM related code opens MMRAM, creates the MMRAM memory map, and
launches the MM Foundation, which provides the necessary services to
launch MM-related drivers. Then, sometime before boot, MMRAM is
closed and locked. This piece may be completed during the
SEC, PEI or DXE phases.
3. MMI Management
When an MMI generated, the MM environment is created and then the MMI
sources are detected and MMI handlers called.
This patch implements the MM Core.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Sughosh Ganu <sughosh.ganu@arm.com>
Signed-off-by: Supreeth Venkatesh <supreeth.venkatesh@arm.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
2018-07-13 17:05:27 +02:00
|
|
|
STATIC BOOLEAN mInExitBootServices = FALSE;
|
|
|
|
|
2020-12-03 21:52:01 +01:00
|
|
|
Status = EFI_SUCCESS;
|
StandaloneMmPkg/Core: Implementation of Standalone MM Core Module.
Management Mode (MM) is a generic term used to describe a secure
execution environment provided by the CPU and related silicon that is
entered when the CPU detects a MMI. For x86 systems, this can be
implemented with System Management Mode (SMM). For ARM systems, this can
be implemented with TrustZone (TZ).
A MMI can be a CPU instruction or interrupt. Upon detection of a MMI, a
CPU will jump to the MM Entry Point and save some portion of its state
(the "save state") such that execution can be resumed.
The MMI can be generated synchronously by software or asynchronously by
a hardware event. Each MMI source can be detected, cleared and disabled.
Some systems provide for special memory (Management Mode RAM or MMRAM)
which is set aside for software running in MM. Usually the MMRAM is
hidden during normal CPU execution, but this is not required. Usually,
after MMRAM is hidden it cannot be exposed until the next system reset.
The MM Core Interface Specification describes three pieces of the PI
Management Mode architecture:
1. MM Dispatch
During DXE, the DXE Foundation works with the MM Foundation to
schedule MM drivers for execution in the discovered firmware volumes.
2. MM Initialization
MM related code opens MMRAM, creates the MMRAM memory map, and
launches the MM Foundation, which provides the necessary services to
launch MM-related drivers. Then, sometime before boot, MMRAM is
closed and locked. This piece may be completed during the
SEC, PEI or DXE phases.
3. MMI Management
When an MMI generated, the MM environment is created and then the MMI
sources are detected and MMI handlers called.
This patch implements the MM Core.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Sughosh Ganu <sughosh.ganu@arm.com>
Signed-off-by: Supreeth Venkatesh <supreeth.venkatesh@arm.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
2018-07-13 17:05:27 +02:00
|
|
|
if (!mInExitBootServices) {
|
|
|
|
MmHandle = NULL;
|
|
|
|
Status = MmInstallProtocolInterface (
|
|
|
|
&MmHandle,
|
|
|
|
&gEfiEventExitBootServicesGuid,
|
|
|
|
EFI_NATIVE_INTERFACE,
|
|
|
|
NULL
|
|
|
|
);
|
|
|
|
}
|
2021-12-05 23:54:16 +01:00
|
|
|
|
StandaloneMmPkg/Core: Implementation of Standalone MM Core Module.
Management Mode (MM) is a generic term used to describe a secure
execution environment provided by the CPU and related silicon that is
entered when the CPU detects a MMI. For x86 systems, this can be
implemented with System Management Mode (SMM). For ARM systems, this can
be implemented with TrustZone (TZ).
A MMI can be a CPU instruction or interrupt. Upon detection of a MMI, a
CPU will jump to the MM Entry Point and save some portion of its state
(the "save state") such that execution can be resumed.
The MMI can be generated synchronously by software or asynchronously by
a hardware event. Each MMI source can be detected, cleared and disabled.
Some systems provide for special memory (Management Mode RAM or MMRAM)
which is set aside for software running in MM. Usually the MMRAM is
hidden during normal CPU execution, but this is not required. Usually,
after MMRAM is hidden it cannot be exposed until the next system reset.
The MM Core Interface Specification describes three pieces of the PI
Management Mode architecture:
1. MM Dispatch
During DXE, the DXE Foundation works with the MM Foundation to
schedule MM drivers for execution in the discovered firmware volumes.
2. MM Initialization
MM related code opens MMRAM, creates the MMRAM memory map, and
launches the MM Foundation, which provides the necessary services to
launch MM-related drivers. Then, sometime before boot, MMRAM is
closed and locked. This piece may be completed during the
SEC, PEI or DXE phases.
3. MMI Management
When an MMI generated, the MM environment is created and then the MMI
sources are detected and MMI handlers called.
This patch implements the MM Core.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Sughosh Ganu <sughosh.ganu@arm.com>
Signed-off-by: Supreeth Venkatesh <supreeth.venkatesh@arm.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
2018-07-13 17:05:27 +02:00
|
|
|
mInExitBootServices = TRUE;
|
|
|
|
return Status;
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
Software MMI handler that is called when a ExitBoot Service event is signaled.
|
|
|
|
|
|
|
|
@param DispatchHandle The unique handle assigned to this handler by MmiHandlerRegister().
|
|
|
|
@param Context Points to an optional handler context which was specified when the handler was registered.
|
|
|
|
@param CommBuffer A pointer to a collection of data in memory that will
|
|
|
|
be conveyed from a non-MM environment into an MM environment.
|
|
|
|
@param CommBufferSize The size of the CommBuffer.
|
|
|
|
|
|
|
|
@return Status Code
|
|
|
|
|
|
|
|
**/
|
|
|
|
EFI_STATUS
|
|
|
|
EFIAPI
|
|
|
|
MmReadyToBootHandler (
|
|
|
|
IN EFI_HANDLE DispatchHandle,
|
2021-12-03 03:00:59 +01:00
|
|
|
IN CONST VOID *Context OPTIONAL,
|
|
|
|
IN OUT VOID *CommBuffer OPTIONAL,
|
StandaloneMmPkg/Core: Implementation of Standalone MM Core Module.
Management Mode (MM) is a generic term used to describe a secure
execution environment provided by the CPU and related silicon that is
entered when the CPU detects a MMI. For x86 systems, this can be
implemented with System Management Mode (SMM). For ARM systems, this can
be implemented with TrustZone (TZ).
A MMI can be a CPU instruction or interrupt. Upon detection of a MMI, a
CPU will jump to the MM Entry Point and save some portion of its state
(the "save state") such that execution can be resumed.
The MMI can be generated synchronously by software or asynchronously by
a hardware event. Each MMI source can be detected, cleared and disabled.
Some systems provide for special memory (Management Mode RAM or MMRAM)
which is set aside for software running in MM. Usually the MMRAM is
hidden during normal CPU execution, but this is not required. Usually,
after MMRAM is hidden it cannot be exposed until the next system reset.
The MM Core Interface Specification describes three pieces of the PI
Management Mode architecture:
1. MM Dispatch
During DXE, the DXE Foundation works with the MM Foundation to
schedule MM drivers for execution in the discovered firmware volumes.
2. MM Initialization
MM related code opens MMRAM, creates the MMRAM memory map, and
launches the MM Foundation, which provides the necessary services to
launch MM-related drivers. Then, sometime before boot, MMRAM is
closed and locked. This piece may be completed during the
SEC, PEI or DXE phases.
3. MMI Management
When an MMI generated, the MM environment is created and then the MMI
sources are detected and MMI handlers called.
This patch implements the MM Core.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Sughosh Ganu <sughosh.ganu@arm.com>
Signed-off-by: Supreeth Venkatesh <supreeth.venkatesh@arm.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
2018-07-13 17:05:27 +02:00
|
|
|
IN OUT UINTN *CommBufferSize OPTIONAL
|
|
|
|
)
|
|
|
|
{
|
|
|
|
EFI_HANDLE MmHandle;
|
2020-12-03 21:52:01 +01:00
|
|
|
EFI_STATUS Status;
|
StandaloneMmPkg/Core: Implementation of Standalone MM Core Module.
Management Mode (MM) is a generic term used to describe a secure
execution environment provided by the CPU and related silicon that is
entered when the CPU detects a MMI. For x86 systems, this can be
implemented with System Management Mode (SMM). For ARM systems, this can
be implemented with TrustZone (TZ).
A MMI can be a CPU instruction or interrupt. Upon detection of a MMI, a
CPU will jump to the MM Entry Point and save some portion of its state
(the "save state") such that execution can be resumed.
The MMI can be generated synchronously by software or asynchronously by
a hardware event. Each MMI source can be detected, cleared and disabled.
Some systems provide for special memory (Management Mode RAM or MMRAM)
which is set aside for software running in MM. Usually the MMRAM is
hidden during normal CPU execution, but this is not required. Usually,
after MMRAM is hidden it cannot be exposed until the next system reset.
The MM Core Interface Specification describes three pieces of the PI
Management Mode architecture:
1. MM Dispatch
During DXE, the DXE Foundation works with the MM Foundation to
schedule MM drivers for execution in the discovered firmware volumes.
2. MM Initialization
MM related code opens MMRAM, creates the MMRAM memory map, and
launches the MM Foundation, which provides the necessary services to
launch MM-related drivers. Then, sometime before boot, MMRAM is
closed and locked. This piece may be completed during the
SEC, PEI or DXE phases.
3. MMI Management
When an MMI generated, the MM environment is created and then the MMI
sources are detected and MMI handlers called.
This patch implements the MM Core.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Sughosh Ganu <sughosh.ganu@arm.com>
Signed-off-by: Supreeth Venkatesh <supreeth.venkatesh@arm.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
2018-07-13 17:05:27 +02:00
|
|
|
STATIC BOOLEAN mInReadyToBoot = FALSE;
|
|
|
|
|
2020-12-03 21:52:01 +01:00
|
|
|
Status = EFI_SUCCESS;
|
StandaloneMmPkg/Core: Implementation of Standalone MM Core Module.
Management Mode (MM) is a generic term used to describe a secure
execution environment provided by the CPU and related silicon that is
entered when the CPU detects a MMI. For x86 systems, this can be
implemented with System Management Mode (SMM). For ARM systems, this can
be implemented with TrustZone (TZ).
A MMI can be a CPU instruction or interrupt. Upon detection of a MMI, a
CPU will jump to the MM Entry Point and save some portion of its state
(the "save state") such that execution can be resumed.
The MMI can be generated synchronously by software or asynchronously by
a hardware event. Each MMI source can be detected, cleared and disabled.
Some systems provide for special memory (Management Mode RAM or MMRAM)
which is set aside for software running in MM. Usually the MMRAM is
hidden during normal CPU execution, but this is not required. Usually,
after MMRAM is hidden it cannot be exposed until the next system reset.
The MM Core Interface Specification describes three pieces of the PI
Management Mode architecture:
1. MM Dispatch
During DXE, the DXE Foundation works with the MM Foundation to
schedule MM drivers for execution in the discovered firmware volumes.
2. MM Initialization
MM related code opens MMRAM, creates the MMRAM memory map, and
launches the MM Foundation, which provides the necessary services to
launch MM-related drivers. Then, sometime before boot, MMRAM is
closed and locked. This piece may be completed during the
SEC, PEI or DXE phases.
3. MMI Management
When an MMI generated, the MM environment is created and then the MMI
sources are detected and MMI handlers called.
This patch implements the MM Core.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Sughosh Ganu <sughosh.ganu@arm.com>
Signed-off-by: Supreeth Venkatesh <supreeth.venkatesh@arm.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
2018-07-13 17:05:27 +02:00
|
|
|
if (!mInReadyToBoot) {
|
|
|
|
MmHandle = NULL;
|
|
|
|
Status = MmInstallProtocolInterface (
|
|
|
|
&MmHandle,
|
|
|
|
&gEfiEventReadyToBootGuid,
|
|
|
|
EFI_NATIVE_INTERFACE,
|
|
|
|
NULL
|
|
|
|
);
|
|
|
|
}
|
2021-12-05 23:54:16 +01:00
|
|
|
|
StandaloneMmPkg/Core: Implementation of Standalone MM Core Module.
Management Mode (MM) is a generic term used to describe a secure
execution environment provided by the CPU and related silicon that is
entered when the CPU detects a MMI. For x86 systems, this can be
implemented with System Management Mode (SMM). For ARM systems, this can
be implemented with TrustZone (TZ).
A MMI can be a CPU instruction or interrupt. Upon detection of a MMI, a
CPU will jump to the MM Entry Point and save some portion of its state
(the "save state") such that execution can be resumed.
The MMI can be generated synchronously by software or asynchronously by
a hardware event. Each MMI source can be detected, cleared and disabled.
Some systems provide for special memory (Management Mode RAM or MMRAM)
which is set aside for software running in MM. Usually the MMRAM is
hidden during normal CPU execution, but this is not required. Usually,
after MMRAM is hidden it cannot be exposed until the next system reset.
The MM Core Interface Specification describes three pieces of the PI
Management Mode architecture:
1. MM Dispatch
During DXE, the DXE Foundation works with the MM Foundation to
schedule MM drivers for execution in the discovered firmware volumes.
2. MM Initialization
MM related code opens MMRAM, creates the MMRAM memory map, and
launches the MM Foundation, which provides the necessary services to
launch MM-related drivers. Then, sometime before boot, MMRAM is
closed and locked. This piece may be completed during the
SEC, PEI or DXE phases.
3. MMI Management
When an MMI generated, the MM environment is created and then the MMI
sources are detected and MMI handlers called.
This patch implements the MM Core.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Sughosh Ganu <sughosh.ganu@arm.com>
Signed-off-by: Supreeth Venkatesh <supreeth.venkatesh@arm.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
2018-07-13 17:05:27 +02:00
|
|
|
mInReadyToBoot = TRUE;
|
|
|
|
return Status;
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
Software MMI handler that is called when the DxeMmReadyToLock protocol is added
|
|
|
|
or if gEfiEventReadyToBootGuid is signaled. This function unregisters the
|
|
|
|
Software SMIs that are nor required after MMRAM is locked and installs the
|
|
|
|
MM Ready To Lock Protocol so MM Drivers are informed that MMRAM is about
|
|
|
|
to be locked.
|
|
|
|
|
|
|
|
@param DispatchHandle The unique handle assigned to this handler by MmiHandlerRegister().
|
|
|
|
@param Context Points to an optional handler context which was specified when the handler was registered.
|
|
|
|
@param CommBuffer A pointer to a collection of data in memory that will
|
|
|
|
be conveyed from a non-MM environment into an MM environment.
|
|
|
|
@param CommBufferSize The size of the CommBuffer.
|
|
|
|
|
|
|
|
@return Status Code
|
|
|
|
|
|
|
|
**/
|
|
|
|
EFI_STATUS
|
|
|
|
EFIAPI
|
|
|
|
MmReadyToLockHandler (
|
|
|
|
IN EFI_HANDLE DispatchHandle,
|
2021-12-03 03:00:59 +01:00
|
|
|
IN CONST VOID *Context OPTIONAL,
|
|
|
|
IN OUT VOID *CommBuffer OPTIONAL,
|
StandaloneMmPkg/Core: Implementation of Standalone MM Core Module.
Management Mode (MM) is a generic term used to describe a secure
execution environment provided by the CPU and related silicon that is
entered when the CPU detects a MMI. For x86 systems, this can be
implemented with System Management Mode (SMM). For ARM systems, this can
be implemented with TrustZone (TZ).
A MMI can be a CPU instruction or interrupt. Upon detection of a MMI, a
CPU will jump to the MM Entry Point and save some portion of its state
(the "save state") such that execution can be resumed.
The MMI can be generated synchronously by software or asynchronously by
a hardware event. Each MMI source can be detected, cleared and disabled.
Some systems provide for special memory (Management Mode RAM or MMRAM)
which is set aside for software running in MM. Usually the MMRAM is
hidden during normal CPU execution, but this is not required. Usually,
after MMRAM is hidden it cannot be exposed until the next system reset.
The MM Core Interface Specification describes three pieces of the PI
Management Mode architecture:
1. MM Dispatch
During DXE, the DXE Foundation works with the MM Foundation to
schedule MM drivers for execution in the discovered firmware volumes.
2. MM Initialization
MM related code opens MMRAM, creates the MMRAM memory map, and
launches the MM Foundation, which provides the necessary services to
launch MM-related drivers. Then, sometime before boot, MMRAM is
closed and locked. This piece may be completed during the
SEC, PEI or DXE phases.
3. MMI Management
When an MMI generated, the MM environment is created and then the MMI
sources are detected and MMI handlers called.
This patch implements the MM Core.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Sughosh Ganu <sughosh.ganu@arm.com>
Signed-off-by: Supreeth Venkatesh <supreeth.venkatesh@arm.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
2018-07-13 17:05:27 +02:00
|
|
|
IN OUT UINTN *CommBufferSize OPTIONAL
|
|
|
|
)
|
|
|
|
{
|
|
|
|
EFI_STATUS Status;
|
|
|
|
UINTN Index;
|
|
|
|
EFI_HANDLE MmHandle;
|
|
|
|
|
|
|
|
DEBUG ((DEBUG_INFO, "MmReadyToLockHandler\n"));
|
|
|
|
|
|
|
|
//
|
|
|
|
// Unregister MMI Handlers that are no longer required after the MM driver dispatch is stopped
|
|
|
|
//
|
|
|
|
for (Index = 0; mMmCoreMmiHandlers[Index].HandlerType != NULL; Index++) {
|
|
|
|
if (mMmCoreMmiHandlers[Index].UnRegister) {
|
|
|
|
MmiHandlerUnRegister (mMmCoreMmiHandlers[Index].DispatchHandle);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
//
|
|
|
|
// Install MM Ready to lock protocol
|
|
|
|
//
|
|
|
|
MmHandle = NULL;
|
|
|
|
Status = MmInstallProtocolInterface (
|
|
|
|
&MmHandle,
|
|
|
|
&gEfiMmReadyToLockProtocolGuid,
|
|
|
|
EFI_NATIVE_INTERFACE,
|
|
|
|
NULL
|
|
|
|
);
|
|
|
|
|
|
|
|
//
|
|
|
|
// Make sure MM CPU I/O 2 Protocol has been installed into the handle database
|
|
|
|
//
|
|
|
|
// Status = MmLocateProtocol (&EFI_MM_CPU_IO_PROTOCOL_GUID, NULL, &Interface);
|
|
|
|
|
|
|
|
//
|
|
|
|
// Print a message on a debug build if the MM CPU I/O 2 Protocol is not installed
|
|
|
|
//
|
|
|
|
// if (EFI_ERROR (Status)) {
|
|
|
|
// DEBUG ((DEBUG_ERROR, "\nSMM: SmmCpuIo Arch Protocol not present!!\n"));
|
|
|
|
// }
|
|
|
|
|
|
|
|
//
|
|
|
|
// Assert if the CPU I/O 2 Protocol is not installed
|
|
|
|
//
|
|
|
|
// ASSERT_EFI_ERROR (Status);
|
|
|
|
|
|
|
|
//
|
|
|
|
// Display any drivers that were not dispatched because dependency expression
|
|
|
|
// evaluated to false if this is a debug build
|
|
|
|
//
|
|
|
|
// MmDisplayDiscoveredNotDispatched ();
|
|
|
|
|
|
|
|
return Status;
|
|
|
|
}
|
|
|
|
|
2024-05-14 04:20:06 +02:00
|
|
|
/**
|
|
|
|
Software MMI handler that is called when the EndOfPei event is signaled.
|
|
|
|
This function installs the MM EndOfPei Protocol so MM Drivers are informed that
|
|
|
|
EndOfPei event is signaled.
|
|
|
|
|
|
|
|
@param DispatchHandle The unique handle assigned to this handler by MmiHandlerRegister().
|
|
|
|
@param Context Points to an optional handler context which was specified when the handler was registered.
|
|
|
|
@param CommBuffer A pointer to a collection of data in memory that will
|
|
|
|
be conveyed from a non-MM environment into an MM environment.
|
|
|
|
@param CommBufferSize The size of the CommBuffer.
|
|
|
|
|
|
|
|
@return Status Code
|
|
|
|
|
|
|
|
**/
|
|
|
|
EFI_STATUS
|
|
|
|
EFIAPI
|
|
|
|
MmEndOfPeiHandler (
|
|
|
|
IN EFI_HANDLE DispatchHandle,
|
|
|
|
IN CONST VOID *Context OPTIONAL,
|
|
|
|
IN OUT VOID *CommBuffer OPTIONAL,
|
|
|
|
IN OUT UINTN *CommBufferSize OPTIONAL
|
|
|
|
)
|
|
|
|
{
|
|
|
|
EFI_STATUS Status;
|
|
|
|
EFI_HANDLE MmHandle;
|
|
|
|
|
|
|
|
DEBUG ((DEBUG_INFO, "MmEndOfPeiHandler\n"));
|
|
|
|
//
|
|
|
|
// Install MM EndOfDxe protocol
|
|
|
|
//
|
|
|
|
MmHandle = NULL;
|
|
|
|
Status = MmInstallProtocolInterface (
|
|
|
|
&MmHandle,
|
|
|
|
&gEfiMmEndOfPeiProtocol,
|
|
|
|
EFI_NATIVE_INTERFACE,
|
|
|
|
NULL
|
|
|
|
);
|
|
|
|
return Status;
|
|
|
|
}
|
|
|
|
|
StandaloneMmPkg/Core: Implementation of Standalone MM Core Module.
Management Mode (MM) is a generic term used to describe a secure
execution environment provided by the CPU and related silicon that is
entered when the CPU detects a MMI. For x86 systems, this can be
implemented with System Management Mode (SMM). For ARM systems, this can
be implemented with TrustZone (TZ).
A MMI can be a CPU instruction or interrupt. Upon detection of a MMI, a
CPU will jump to the MM Entry Point and save some portion of its state
(the "save state") such that execution can be resumed.
The MMI can be generated synchronously by software or asynchronously by
a hardware event. Each MMI source can be detected, cleared and disabled.
Some systems provide for special memory (Management Mode RAM or MMRAM)
which is set aside for software running in MM. Usually the MMRAM is
hidden during normal CPU execution, but this is not required. Usually,
after MMRAM is hidden it cannot be exposed until the next system reset.
The MM Core Interface Specification describes three pieces of the PI
Management Mode architecture:
1. MM Dispatch
During DXE, the DXE Foundation works with the MM Foundation to
schedule MM drivers for execution in the discovered firmware volumes.
2. MM Initialization
MM related code opens MMRAM, creates the MMRAM memory map, and
launches the MM Foundation, which provides the necessary services to
launch MM-related drivers. Then, sometime before boot, MMRAM is
closed and locked. This piece may be completed during the
SEC, PEI or DXE phases.
3. MMI Management
When an MMI generated, the MM environment is created and then the MMI
sources are detected and MMI handlers called.
This patch implements the MM Core.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Sughosh Ganu <sughosh.ganu@arm.com>
Signed-off-by: Supreeth Venkatesh <supreeth.venkatesh@arm.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
2018-07-13 17:05:27 +02:00
|
|
|
/**
|
|
|
|
Software MMI handler that is called when the EndOfDxe event is signaled.
|
|
|
|
This function installs the MM EndOfDxe Protocol so MM Drivers are informed that
|
|
|
|
platform code will invoke 3rd part code.
|
|
|
|
|
|
|
|
@param DispatchHandle The unique handle assigned to this handler by MmiHandlerRegister().
|
|
|
|
@param Context Points to an optional handler context which was specified when the handler was registered.
|
|
|
|
@param CommBuffer A pointer to a collection of data in memory that will
|
|
|
|
be conveyed from a non-MM environment into an MM environment.
|
|
|
|
@param CommBufferSize The size of the CommBuffer.
|
|
|
|
|
|
|
|
@return Status Code
|
|
|
|
|
|
|
|
**/
|
|
|
|
EFI_STATUS
|
|
|
|
EFIAPI
|
|
|
|
MmEndOfDxeHandler (
|
|
|
|
IN EFI_HANDLE DispatchHandle,
|
2021-12-03 03:00:59 +01:00
|
|
|
IN CONST VOID *Context OPTIONAL,
|
|
|
|
IN OUT VOID *CommBuffer OPTIONAL,
|
StandaloneMmPkg/Core: Implementation of Standalone MM Core Module.
Management Mode (MM) is a generic term used to describe a secure
execution environment provided by the CPU and related silicon that is
entered when the CPU detects a MMI. For x86 systems, this can be
implemented with System Management Mode (SMM). For ARM systems, this can
be implemented with TrustZone (TZ).
A MMI can be a CPU instruction or interrupt. Upon detection of a MMI, a
CPU will jump to the MM Entry Point and save some portion of its state
(the "save state") such that execution can be resumed.
The MMI can be generated synchronously by software or asynchronously by
a hardware event. Each MMI source can be detected, cleared and disabled.
Some systems provide for special memory (Management Mode RAM or MMRAM)
which is set aside for software running in MM. Usually the MMRAM is
hidden during normal CPU execution, but this is not required. Usually,
after MMRAM is hidden it cannot be exposed until the next system reset.
The MM Core Interface Specification describes three pieces of the PI
Management Mode architecture:
1. MM Dispatch
During DXE, the DXE Foundation works with the MM Foundation to
schedule MM drivers for execution in the discovered firmware volumes.
2. MM Initialization
MM related code opens MMRAM, creates the MMRAM memory map, and
launches the MM Foundation, which provides the necessary services to
launch MM-related drivers. Then, sometime before boot, MMRAM is
closed and locked. This piece may be completed during the
SEC, PEI or DXE phases.
3. MMI Management
When an MMI generated, the MM environment is created and then the MMI
sources are detected and MMI handlers called.
This patch implements the MM Core.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Sughosh Ganu <sughosh.ganu@arm.com>
Signed-off-by: Supreeth Venkatesh <supreeth.venkatesh@arm.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
2018-07-13 17:05:27 +02:00
|
|
|
IN OUT UINTN *CommBufferSize OPTIONAL
|
|
|
|
)
|
|
|
|
{
|
|
|
|
EFI_STATUS Status;
|
|
|
|
EFI_HANDLE MmHandle;
|
|
|
|
|
|
|
|
DEBUG ((DEBUG_INFO, "MmEndOfDxeHandler\n"));
|
|
|
|
//
|
|
|
|
// Install MM EndOfDxe protocol
|
|
|
|
//
|
|
|
|
MmHandle = NULL;
|
|
|
|
Status = MmInstallProtocolInterface (
|
|
|
|
&MmHandle,
|
|
|
|
&gEfiMmEndOfDxeProtocolGuid,
|
|
|
|
EFI_NATIVE_INTERFACE,
|
|
|
|
NULL
|
|
|
|
);
|
|
|
|
return Status;
|
|
|
|
}
|
|
|
|
|
2024-05-06 19:59:46 +02:00
|
|
|
/**
|
|
|
|
Install LoadedImage protocol for MM Core.
|
|
|
|
|
|
|
|
**/
|
|
|
|
VOID
|
|
|
|
MmCoreInstallLoadedImage (
|
|
|
|
VOID
|
|
|
|
)
|
|
|
|
{
|
|
|
|
EFI_STATUS Status;
|
|
|
|
EFI_PHYSICAL_ADDRESS MmCoreImageBaseAddress;
|
|
|
|
UINT64 MmCoreImageLength;
|
|
|
|
EFI_PEI_HOB_POINTERS Hob;
|
|
|
|
EFI_LOADED_IMAGE_PROTOCOL *LoadedImage;
|
|
|
|
EFI_HANDLE ImageHandle;
|
|
|
|
|
|
|
|
//
|
|
|
|
// Searching for Memory Allocation HOB
|
|
|
|
//
|
|
|
|
Hob.Raw = GetHobList ();
|
|
|
|
while ((Hob.Raw = GetNextHob (EFI_HOB_TYPE_MEMORY_ALLOCATION, Hob.Raw)) != NULL) {
|
|
|
|
//
|
|
|
|
// Find MM Core HOB
|
|
|
|
//
|
|
|
|
if (CompareGuid (
|
|
|
|
&Hob.MemoryAllocationModule->MemoryAllocationHeader.Name,
|
|
|
|
&gEfiHobMemoryAllocModuleGuid
|
|
|
|
))
|
|
|
|
{
|
|
|
|
if (CompareGuid (&Hob.MemoryAllocationModule->ModuleName, &gEfiCallerIdGuid)) {
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
Hob.Raw = GET_NEXT_HOB (Hob);
|
|
|
|
}
|
|
|
|
|
|
|
|
if (Hob.Raw == NULL) {
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
MmCoreImageBaseAddress = Hob.MemoryAllocationModule->MemoryAllocationHeader.MemoryBaseAddress;
|
|
|
|
MmCoreImageLength = Hob.MemoryAllocationModule->MemoryAllocationHeader.MemoryLength;
|
|
|
|
|
|
|
|
//
|
|
|
|
// Allocate a Loaded Image Protocol in MM
|
|
|
|
//
|
|
|
|
LoadedImage = AllocatePool (sizeof (EFI_LOADED_IMAGE_PROTOCOL));
|
|
|
|
ASSERT (LoadedImage != NULL);
|
|
|
|
if (LoadedImage == NULL) {
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
ZeroMem (LoadedImage, sizeof (EFI_LOADED_IMAGE_PROTOCOL));
|
|
|
|
|
|
|
|
//
|
|
|
|
// Fill in the remaining fields of the Loaded Image Protocol instance.
|
|
|
|
//
|
|
|
|
LoadedImage->Revision = EFI_LOADED_IMAGE_PROTOCOL_REVISION;
|
|
|
|
LoadedImage->ParentHandle = NULL;
|
|
|
|
LoadedImage->SystemTable = NULL;
|
|
|
|
|
|
|
|
LoadedImage->ImageBase = (VOID *)(UINTN)MmCoreImageBaseAddress;
|
|
|
|
LoadedImage->ImageSize = MmCoreImageLength;
|
|
|
|
LoadedImage->ImageCodeType = EfiRuntimeServicesCode;
|
|
|
|
LoadedImage->ImageDataType = EfiRuntimeServicesData;
|
|
|
|
|
|
|
|
//
|
|
|
|
// Create a new image handle in the MM handle database for the MM Core
|
|
|
|
//
|
|
|
|
ImageHandle = NULL;
|
|
|
|
Status = MmInstallProtocolInterface (
|
|
|
|
&ImageHandle,
|
|
|
|
&gEfiLoadedImageProtocolGuid,
|
|
|
|
EFI_NATIVE_INTERFACE,
|
|
|
|
LoadedImage
|
|
|
|
);
|
|
|
|
ASSERT_EFI_ERROR (Status);
|
|
|
|
}
|
|
|
|
|
2024-05-13 17:51:45 +02:00
|
|
|
/**
|
|
|
|
Prepare communication buffer for MMI.
|
|
|
|
**/
|
|
|
|
VOID
|
|
|
|
MmCorePrepareCommunicationBuffer (
|
|
|
|
VOID
|
|
|
|
)
|
|
|
|
{
|
|
|
|
EFI_STATUS Status;
|
|
|
|
EFI_HOB_GUID_TYPE *GuidHob;
|
|
|
|
EFI_PHYSICAL_ADDRESS Buffer;
|
|
|
|
|
|
|
|
mMmCommunicationBuffer = NULL;
|
|
|
|
mInternalCommBufferCopy = NULL;
|
|
|
|
|
|
|
|
GuidHob = GetFirstGuidHob (&gMmCommBufferHobGuid);
|
|
|
|
ASSERT (GuidHob != NULL);
|
|
|
|
if (GuidHob == NULL) {
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
mMmCommunicationBuffer = (MM_COMM_BUFFER *)GET_GUID_HOB_DATA (GuidHob);
|
|
|
|
DEBUG ((
|
|
|
|
DEBUG_INFO,
|
|
|
|
"MM Communication Buffer is at %x, number of pages is %x\n",
|
|
|
|
mMmCommunicationBuffer->PhysicalStart,
|
|
|
|
mMmCommunicationBuffer->NumberOfPages
|
|
|
|
));
|
|
|
|
ASSERT (mMmCommunicationBuffer->PhysicalStart != 0 && mMmCommunicationBuffer->NumberOfPages != 0);
|
|
|
|
|
|
|
|
if (!MmIsBufferOutsideMmValid (
|
|
|
|
mMmCommunicationBuffer->PhysicalStart,
|
|
|
|
EFI_PAGES_TO_SIZE (mMmCommunicationBuffer->NumberOfPages)
|
|
|
|
))
|
|
|
|
{
|
|
|
|
mMmCommunicationBuffer = NULL;
|
|
|
|
DEBUG ((DEBUG_ERROR, "MM Communication Buffer is invalid!\n"));
|
|
|
|
ASSERT (FALSE);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
Status = MmAllocatePages (
|
|
|
|
AllocateAnyPages,
|
|
|
|
EfiRuntimeServicesData,
|
|
|
|
mMmCommunicationBuffer->NumberOfPages,
|
|
|
|
&Buffer
|
|
|
|
);
|
|
|
|
ASSERT_EFI_ERROR (Status);
|
|
|
|
if (EFI_ERROR (Status)) {
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
mInternalCommBufferCopy = (VOID *)(UINTN)Buffer;
|
|
|
|
DEBUG ((DEBUG_INFO, "Internal Communication Buffer Copy is at %p\n", mInternalCommBufferCopy));
|
|
|
|
}
|
|
|
|
|
StandaloneMmPkg/Core: Implementation of Standalone MM Core Module.
Management Mode (MM) is a generic term used to describe a secure
execution environment provided by the CPU and related silicon that is
entered when the CPU detects a MMI. For x86 systems, this can be
implemented with System Management Mode (SMM). For ARM systems, this can
be implemented with TrustZone (TZ).
A MMI can be a CPU instruction or interrupt. Upon detection of a MMI, a
CPU will jump to the MM Entry Point and save some portion of its state
(the "save state") such that execution can be resumed.
The MMI can be generated synchronously by software or asynchronously by
a hardware event. Each MMI source can be detected, cleared and disabled.
Some systems provide for special memory (Management Mode RAM or MMRAM)
which is set aside for software running in MM. Usually the MMRAM is
hidden during normal CPU execution, but this is not required. Usually,
after MMRAM is hidden it cannot be exposed until the next system reset.
The MM Core Interface Specification describes three pieces of the PI
Management Mode architecture:
1. MM Dispatch
During DXE, the DXE Foundation works with the MM Foundation to
schedule MM drivers for execution in the discovered firmware volumes.
2. MM Initialization
MM related code opens MMRAM, creates the MMRAM memory map, and
launches the MM Foundation, which provides the necessary services to
launch MM-related drivers. Then, sometime before boot, MMRAM is
closed and locked. This piece may be completed during the
SEC, PEI or DXE phases.
3. MMI Management
When an MMI generated, the MM environment is created and then the MMI
sources are detected and MMI handlers called.
This patch implements the MM Core.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Sughosh Ganu <sughosh.ganu@arm.com>
Signed-off-by: Supreeth Venkatesh <supreeth.venkatesh@arm.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
2018-07-13 17:05:27 +02:00
|
|
|
/**
|
|
|
|
The main entry point to MM Foundation.
|
|
|
|
|
|
|
|
Note: This function is only used by MMRAM invocation. It is never used by DXE invocation.
|
|
|
|
|
|
|
|
@param MmEntryContext Processor information and functionality
|
|
|
|
needed by MM Foundation.
|
|
|
|
|
|
|
|
**/
|
|
|
|
VOID
|
|
|
|
EFIAPI
|
|
|
|
MmEntryPoint (
|
|
|
|
IN CONST EFI_MM_ENTRY_CONTEXT *MmEntryContext
|
|
|
|
)
|
|
|
|
{
|
|
|
|
EFI_STATUS Status;
|
|
|
|
EFI_MM_COMMUNICATE_HEADER *CommunicateHeader;
|
2024-05-13 17:51:45 +02:00
|
|
|
MM_COMM_BUFFER_STATUS *CommunicationStatus;
|
|
|
|
UINTN BufferSize;
|
StandaloneMmPkg/Core: Implementation of Standalone MM Core Module.
Management Mode (MM) is a generic term used to describe a secure
execution environment provided by the CPU and related silicon that is
entered when the CPU detects a MMI. For x86 systems, this can be
implemented with System Management Mode (SMM). For ARM systems, this can
be implemented with TrustZone (TZ).
A MMI can be a CPU instruction or interrupt. Upon detection of a MMI, a
CPU will jump to the MM Entry Point and save some portion of its state
(the "save state") such that execution can be resumed.
The MMI can be generated synchronously by software or asynchronously by
a hardware event. Each MMI source can be detected, cleared and disabled.
Some systems provide for special memory (Management Mode RAM or MMRAM)
which is set aside for software running in MM. Usually the MMRAM is
hidden during normal CPU execution, but this is not required. Usually,
after MMRAM is hidden it cannot be exposed until the next system reset.
The MM Core Interface Specification describes three pieces of the PI
Management Mode architecture:
1. MM Dispatch
During DXE, the DXE Foundation works with the MM Foundation to
schedule MM drivers for execution in the discovered firmware volumes.
2. MM Initialization
MM related code opens MMRAM, creates the MMRAM memory map, and
launches the MM Foundation, which provides the necessary services to
launch MM-related drivers. Then, sometime before boot, MMRAM is
closed and locked. This piece may be completed during the
SEC, PEI or DXE phases.
3. MMI Management
When an MMI generated, the MM environment is created and then the MMI
sources are detected and MMI handlers called.
This patch implements the MM Core.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Sughosh Ganu <sughosh.ganu@arm.com>
Signed-off-by: Supreeth Venkatesh <supreeth.venkatesh@arm.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
2018-07-13 17:05:27 +02:00
|
|
|
|
|
|
|
DEBUG ((DEBUG_INFO, "MmEntryPoint ...\n"));
|
|
|
|
|
|
|
|
//
|
|
|
|
// Update MMST using the context
|
|
|
|
//
|
|
|
|
CopyMem (&gMmCoreMmst.MmStartupThisAp, MmEntryContext, sizeof (EFI_MM_ENTRY_CONTEXT));
|
|
|
|
|
|
|
|
//
|
|
|
|
// Call platform hook before Mm Dispatch
|
|
|
|
//
|
|
|
|
// PlatformHookBeforeMmDispatch ();
|
|
|
|
|
2019-03-05 10:14:12 +01:00
|
|
|
//
|
|
|
|
// Check to see if this is a Synchronous MMI sent through the MM Communication
|
|
|
|
// Protocol or an Asynchronous MMI
|
|
|
|
//
|
2024-05-13 17:51:45 +02:00
|
|
|
if ((mMmCommunicationBuffer != NULL) && (mInternalCommBufferCopy != NULL)) {
|
|
|
|
CommunicationStatus = (MM_COMM_BUFFER_STATUS *)(UINTN)mMmCommunicationBuffer->Status;
|
|
|
|
if (CommunicationStatus->IsCommBufferValid) {
|
2019-03-05 10:14:12 +01:00
|
|
|
//
|
2024-05-13 17:51:45 +02:00
|
|
|
// Synchronous MMI for MM Core or request from Communicate protocol
|
2019-03-05 10:14:12 +01:00
|
|
|
//
|
2024-05-13 17:51:45 +02:00
|
|
|
CommunicateHeader = (EFI_MM_COMMUNICATE_HEADER *)(UINTN)mMmCommunicationBuffer->PhysicalStart;
|
|
|
|
BufferSize = OFFSET_OF (EFI_MM_COMMUNICATE_HEADER, Data) + CommunicateHeader->MessageLength;
|
|
|
|
if (BufferSize <= EFI_PAGES_TO_SIZE (mMmCommunicationBuffer->NumberOfPages)) {
|
|
|
|
//
|
|
|
|
// Shadow the data from MM Communication Buffer to internal buffer
|
|
|
|
//
|
|
|
|
CopyMem (
|
|
|
|
mInternalCommBufferCopy,
|
|
|
|
(VOID *)(UINTN)mMmCommunicationBuffer->PhysicalStart,
|
|
|
|
BufferSize
|
|
|
|
);
|
|
|
|
ZeroMem (
|
|
|
|
(UINT8 *)mInternalCommBufferCopy + BufferSize,
|
|
|
|
EFI_PAGES_TO_SIZE (mMmCommunicationBuffer->NumberOfPages) - BufferSize
|
|
|
|
);
|
|
|
|
|
|
|
|
CommunicateHeader = (EFI_MM_COMMUNICATE_HEADER *)mInternalCommBufferCopy;
|
|
|
|
BufferSize = CommunicateHeader->MessageLength;
|
|
|
|
Status = MmiManage (
|
|
|
|
&CommunicateHeader->HeaderGuid,
|
|
|
|
NULL,
|
|
|
|
CommunicateHeader->Data,
|
|
|
|
&BufferSize
|
|
|
|
);
|
|
|
|
|
|
|
|
BufferSize = BufferSize + OFFSET_OF (EFI_MM_COMMUNICATE_HEADER, Data);
|
|
|
|
if (BufferSize <= EFI_PAGES_TO_SIZE (mMmCommunicationBuffer->NumberOfPages)) {
|
|
|
|
//
|
|
|
|
// Copy the data back to MM Communication Buffer
|
|
|
|
//
|
|
|
|
CopyMem (
|
|
|
|
(VOID *)(UINTN)mMmCommunicationBuffer->PhysicalStart,
|
|
|
|
mInternalCommBufferCopy,
|
|
|
|
BufferSize
|
|
|
|
);
|
|
|
|
} else {
|
|
|
|
DEBUG ((DEBUG_ERROR, "Returned buffer size is larger than the size of MM Communication Buffer\n"));
|
|
|
|
ASSERT (FALSE);
|
|
|
|
}
|
|
|
|
|
|
|
|
//
|
2024-10-20 18:07:22 +02:00
|
|
|
// Update ReturnBufferSize and ReturnStatus
|
|
|
|
// Communicate service finished, reset IsCommBufferValid to FALSE
|
2024-05-13 17:51:45 +02:00
|
|
|
//
|
2024-10-20 18:07:22 +02:00
|
|
|
CommunicationStatus->IsCommBufferValid = FALSE;
|
|
|
|
CommunicationStatus->ReturnBufferSize = BufferSize;
|
|
|
|
CommunicationStatus->ReturnStatus = (Status == EFI_SUCCESS) ? EFI_SUCCESS : EFI_NOT_FOUND;
|
2024-05-13 17:51:45 +02:00
|
|
|
} else {
|
|
|
|
DEBUG ((DEBUG_ERROR, "Input buffer size is larger than the size of MM Communication Buffer\n"));
|
|
|
|
ASSERT (FALSE);
|
|
|
|
}
|
StandaloneMmPkg/Core: Implementation of Standalone MM Core Module.
Management Mode (MM) is a generic term used to describe a secure
execution environment provided by the CPU and related silicon that is
entered when the CPU detects a MMI. For x86 systems, this can be
implemented with System Management Mode (SMM). For ARM systems, this can
be implemented with TrustZone (TZ).
A MMI can be a CPU instruction or interrupt. Upon detection of a MMI, a
CPU will jump to the MM Entry Point and save some portion of its state
(the "save state") such that execution can be resumed.
The MMI can be generated synchronously by software or asynchronously by
a hardware event. Each MMI source can be detected, cleared and disabled.
Some systems provide for special memory (Management Mode RAM or MMRAM)
which is set aside for software running in MM. Usually the MMRAM is
hidden during normal CPU execution, but this is not required. Usually,
after MMRAM is hidden it cannot be exposed until the next system reset.
The MM Core Interface Specification describes three pieces of the PI
Management Mode architecture:
1. MM Dispatch
During DXE, the DXE Foundation works with the MM Foundation to
schedule MM drivers for execution in the discovered firmware volumes.
2. MM Initialization
MM related code opens MMRAM, creates the MMRAM memory map, and
launches the MM Foundation, which provides the necessary services to
launch MM-related drivers. Then, sometime before boot, MMRAM is
closed and locked. This piece may be completed during the
SEC, PEI or DXE phases.
3. MMI Management
When an MMI generated, the MM environment is created and then the MMI
sources are detected and MMI handlers called.
This patch implements the MM Core.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Sughosh Ganu <sughosh.ganu@arm.com>
Signed-off-by: Supreeth Venkatesh <supreeth.venkatesh@arm.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
2018-07-13 17:05:27 +02:00
|
|
|
}
|
2024-05-13 17:51:45 +02:00
|
|
|
} else {
|
|
|
|
DEBUG ((DEBUG_ERROR, "No valid communication buffer, no Synchronous MMI will be processed\n"));
|
StandaloneMmPkg/Core: Implementation of Standalone MM Core Module.
Management Mode (MM) is a generic term used to describe a secure
execution environment provided by the CPU and related silicon that is
entered when the CPU detects a MMI. For x86 systems, this can be
implemented with System Management Mode (SMM). For ARM systems, this can
be implemented with TrustZone (TZ).
A MMI can be a CPU instruction or interrupt. Upon detection of a MMI, a
CPU will jump to the MM Entry Point and save some portion of its state
(the "save state") such that execution can be resumed.
The MMI can be generated synchronously by software or asynchronously by
a hardware event. Each MMI source can be detected, cleared and disabled.
Some systems provide for special memory (Management Mode RAM or MMRAM)
which is set aside for software running in MM. Usually the MMRAM is
hidden during normal CPU execution, but this is not required. Usually,
after MMRAM is hidden it cannot be exposed until the next system reset.
The MM Core Interface Specification describes three pieces of the PI
Management Mode architecture:
1. MM Dispatch
During DXE, the DXE Foundation works with the MM Foundation to
schedule MM drivers for execution in the discovered firmware volumes.
2. MM Initialization
MM related code opens MMRAM, creates the MMRAM memory map, and
launches the MM Foundation, which provides the necessary services to
launch MM-related drivers. Then, sometime before boot, MMRAM is
closed and locked. This piece may be completed during the
SEC, PEI or DXE phases.
3. MMI Management
When an MMI generated, the MM environment is created and then the MMI
sources are detected and MMI handlers called.
This patch implements the MM Core.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Sughosh Ganu <sughosh.ganu@arm.com>
Signed-off-by: Supreeth Venkatesh <supreeth.venkatesh@arm.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
2018-07-13 17:05:27 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
//
|
|
|
|
// Process Asynchronous MMI sources
|
|
|
|
//
|
|
|
|
MmiManage (NULL, NULL, NULL, NULL);
|
|
|
|
|
|
|
|
//
|
|
|
|
// TBD: Do not use private data structure ?
|
|
|
|
//
|
|
|
|
|
|
|
|
DEBUG ((DEBUG_INFO, "MmEntryPoint Done\n"));
|
|
|
|
}
|
|
|
|
|
2020-12-07 12:04:26 +01:00
|
|
|
/** Register the MM Entry Point provided by the MM Core with the
|
|
|
|
MM Configuration protocol.
|
|
|
|
|
|
|
|
@param [in] Protocol Pointer to the protocol.
|
|
|
|
@param [in] Interface Pointer to the MM Configuration protocol.
|
|
|
|
@param [in] Handle Handle.
|
|
|
|
|
|
|
|
@retval EFI_SUCCESS Success.
|
|
|
|
**/
|
StandaloneMmPkg/Core: Implementation of Standalone MM Core Module.
Management Mode (MM) is a generic term used to describe a secure
execution environment provided by the CPU and related silicon that is
entered when the CPU detects a MMI. For x86 systems, this can be
implemented with System Management Mode (SMM). For ARM systems, this can
be implemented with TrustZone (TZ).
A MMI can be a CPU instruction or interrupt. Upon detection of a MMI, a
CPU will jump to the MM Entry Point and save some portion of its state
(the "save state") such that execution can be resumed.
The MMI can be generated synchronously by software or asynchronously by
a hardware event. Each MMI source can be detected, cleared and disabled.
Some systems provide for special memory (Management Mode RAM or MMRAM)
which is set aside for software running in MM. Usually the MMRAM is
hidden during normal CPU execution, but this is not required. Usually,
after MMRAM is hidden it cannot be exposed until the next system reset.
The MM Core Interface Specification describes three pieces of the PI
Management Mode architecture:
1. MM Dispatch
During DXE, the DXE Foundation works with the MM Foundation to
schedule MM drivers for execution in the discovered firmware volumes.
2. MM Initialization
MM related code opens MMRAM, creates the MMRAM memory map, and
launches the MM Foundation, which provides the necessary services to
launch MM-related drivers. Then, sometime before boot, MMRAM is
closed and locked. This piece may be completed during the
SEC, PEI or DXE phases.
3. MMI Management
When an MMI generated, the MM environment is created and then the MMI
sources are detected and MMI handlers called.
This patch implements the MM Core.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Sughosh Ganu <sughosh.ganu@arm.com>
Signed-off-by: Supreeth Venkatesh <supreeth.venkatesh@arm.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
2018-07-13 17:05:27 +02:00
|
|
|
EFI_STATUS
|
|
|
|
EFIAPI
|
|
|
|
MmConfigurationMmNotify (
|
|
|
|
IN CONST EFI_GUID *Protocol,
|
|
|
|
IN VOID *Interface,
|
|
|
|
IN EFI_HANDLE Handle
|
|
|
|
)
|
|
|
|
{
|
|
|
|
EFI_STATUS Status;
|
|
|
|
EFI_MM_CONFIGURATION_PROTOCOL *MmConfiguration;
|
|
|
|
|
|
|
|
DEBUG ((DEBUG_INFO, "MmConfigurationMmNotify(%g) - %x\n", Protocol, Interface));
|
|
|
|
|
|
|
|
MmConfiguration = Interface;
|
|
|
|
|
|
|
|
//
|
|
|
|
// Register the MM Entry Point provided by the MM Core with the MM COnfiguration protocol
|
|
|
|
//
|
2024-05-13 18:56:58 +02:00
|
|
|
Status = MmConfiguration->RegisterMmEntry (MmConfiguration, (EFI_MM_ENTRY_POINT)MmEntryPoint);
|
StandaloneMmPkg/Core: Implementation of Standalone MM Core Module.
Management Mode (MM) is a generic term used to describe a secure
execution environment provided by the CPU and related silicon that is
entered when the CPU detects a MMI. For x86 systems, this can be
implemented with System Management Mode (SMM). For ARM systems, this can
be implemented with TrustZone (TZ).
A MMI can be a CPU instruction or interrupt. Upon detection of a MMI, a
CPU will jump to the MM Entry Point and save some portion of its state
(the "save state") such that execution can be resumed.
The MMI can be generated synchronously by software or asynchronously by
a hardware event. Each MMI source can be detected, cleared and disabled.
Some systems provide for special memory (Management Mode RAM or MMRAM)
which is set aside for software running in MM. Usually the MMRAM is
hidden during normal CPU execution, but this is not required. Usually,
after MMRAM is hidden it cannot be exposed until the next system reset.
The MM Core Interface Specification describes three pieces of the PI
Management Mode architecture:
1. MM Dispatch
During DXE, the DXE Foundation works with the MM Foundation to
schedule MM drivers for execution in the discovered firmware volumes.
2. MM Initialization
MM related code opens MMRAM, creates the MMRAM memory map, and
launches the MM Foundation, which provides the necessary services to
launch MM-related drivers. Then, sometime before boot, MMRAM is
closed and locked. This piece may be completed during the
SEC, PEI or DXE phases.
3. MMI Management
When an MMI generated, the MM environment is created and then the MMI
sources are detected and MMI handlers called.
This patch implements the MM Core.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Sughosh Ganu <sughosh.ganu@arm.com>
Signed-off-by: Supreeth Venkatesh <supreeth.venkatesh@arm.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
2018-07-13 17:05:27 +02:00
|
|
|
ASSERT_EFI_ERROR (Status);
|
|
|
|
|
|
|
|
//
|
|
|
|
// Set flag to indicate that the MM Entry Point has been registered which
|
|
|
|
// means that MMIs are now fully operational.
|
|
|
|
//
|
2024-05-13 18:56:58 +02:00
|
|
|
mMmEntryPointRegistered = TRUE;
|
StandaloneMmPkg/Core: Implementation of Standalone MM Core Module.
Management Mode (MM) is a generic term used to describe a secure
execution environment provided by the CPU and related silicon that is
entered when the CPU detects a MMI. For x86 systems, this can be
implemented with System Management Mode (SMM). For ARM systems, this can
be implemented with TrustZone (TZ).
A MMI can be a CPU instruction or interrupt. Upon detection of a MMI, a
CPU will jump to the MM Entry Point and save some portion of its state
(the "save state") such that execution can be resumed.
The MMI can be generated synchronously by software or asynchronously by
a hardware event. Each MMI source can be detected, cleared and disabled.
Some systems provide for special memory (Management Mode RAM or MMRAM)
which is set aside for software running in MM. Usually the MMRAM is
hidden during normal CPU execution, but this is not required. Usually,
after MMRAM is hidden it cannot be exposed until the next system reset.
The MM Core Interface Specification describes three pieces of the PI
Management Mode architecture:
1. MM Dispatch
During DXE, the DXE Foundation works with the MM Foundation to
schedule MM drivers for execution in the discovered firmware volumes.
2. MM Initialization
MM related code opens MMRAM, creates the MMRAM memory map, and
launches the MM Foundation, which provides the necessary services to
launch MM-related drivers. Then, sometime before boot, MMRAM is
closed and locked. This piece may be completed during the
SEC, PEI or DXE phases.
3. MMI Management
When an MMI generated, the MM environment is created and then the MMI
sources are detected and MMI handlers called.
This patch implements the MM Core.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Sughosh Ganu <sughosh.ganu@arm.com>
Signed-off-by: Supreeth Venkatesh <supreeth.venkatesh@arm.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
2018-07-13 17:05:27 +02:00
|
|
|
|
|
|
|
//
|
|
|
|
// Print debug message showing MM Core entry point address.
|
|
|
|
//
|
2024-05-13 18:56:58 +02:00
|
|
|
DEBUG ((DEBUG_INFO, "MM Core registered MM Entry Point address %p\n", MmEntryPoint));
|
StandaloneMmPkg/Core: Implementation of Standalone MM Core Module.
Management Mode (MM) is a generic term used to describe a secure
execution environment provided by the CPU and related silicon that is
entered when the CPU detects a MMI. For x86 systems, this can be
implemented with System Management Mode (SMM). For ARM systems, this can
be implemented with TrustZone (TZ).
A MMI can be a CPU instruction or interrupt. Upon detection of a MMI, a
CPU will jump to the MM Entry Point and save some portion of its state
(the "save state") such that execution can be resumed.
The MMI can be generated synchronously by software or asynchronously by
a hardware event. Each MMI source can be detected, cleared and disabled.
Some systems provide for special memory (Management Mode RAM or MMRAM)
which is set aside for software running in MM. Usually the MMRAM is
hidden during normal CPU execution, but this is not required. Usually,
after MMRAM is hidden it cannot be exposed until the next system reset.
The MM Core Interface Specification describes three pieces of the PI
Management Mode architecture:
1. MM Dispatch
During DXE, the DXE Foundation works with the MM Foundation to
schedule MM drivers for execution in the discovered firmware volumes.
2. MM Initialization
MM related code opens MMRAM, creates the MMRAM memory map, and
launches the MM Foundation, which provides the necessary services to
launch MM-related drivers. Then, sometime before boot, MMRAM is
closed and locked. This piece may be completed during the
SEC, PEI or DXE phases.
3. MMI Management
When an MMI generated, the MM environment is created and then the MMI
sources are detected and MMI handlers called.
This patch implements the MM Core.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Sughosh Ganu <sughosh.ganu@arm.com>
Signed-off-by: Supreeth Venkatesh <supreeth.venkatesh@arm.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
2018-07-13 17:05:27 +02:00
|
|
|
return EFI_SUCCESS;
|
|
|
|
}
|
|
|
|
|
2024-06-21 09:04:57 +02:00
|
|
|
/**
|
|
|
|
Migrate MemoryBaseAddress in memory allocation HOBs with BootServiceData
|
|
|
|
type and non-zero GUID name from Boot Service memory to MMRAM.
|
|
|
|
|
|
|
|
@param[in] HobStart Pointer to the start of the HOB list.
|
|
|
|
|
|
|
|
**/
|
|
|
|
VOID
|
|
|
|
MigrateMemoryAllocationHobs (
|
|
|
|
IN VOID *HobStart
|
|
|
|
)
|
|
|
|
{
|
|
|
|
EFI_PEI_HOB_POINTERS Hob;
|
|
|
|
EFI_HOB_MEMORY_ALLOCATION *MemoryAllocationHob;
|
|
|
|
VOID *MemoryInMmram;
|
|
|
|
|
|
|
|
MemoryAllocationHob = NULL;
|
|
|
|
Hob.Raw = GetNextHob (EFI_HOB_TYPE_MEMORY_ALLOCATION, HobStart);
|
|
|
|
while (Hob.Raw != NULL) {
|
|
|
|
MemoryAllocationHob = (EFI_HOB_MEMORY_ALLOCATION *)Hob.Raw;
|
2024-11-01 05:19:36 +01:00
|
|
|
if (MemoryAllocationHob->AllocDescriptor.MemoryType == EfiBootServicesData) {
|
2024-06-21 09:04:57 +02:00
|
|
|
if (!IsZeroGuid (&MemoryAllocationHob->AllocDescriptor.Name)) {
|
|
|
|
MemoryInMmram = AllocatePages (EFI_SIZE_TO_PAGES (MemoryAllocationHob->AllocDescriptor.MemoryLength));
|
|
|
|
if (MemoryInMmram != NULL) {
|
|
|
|
DEBUG ((
|
|
|
|
DEBUG_INFO,
|
|
|
|
"Migrate Memory Allocation Hob (%g) from %08x to %08p\n",
|
|
|
|
&MemoryAllocationHob->AllocDescriptor.Name,
|
|
|
|
MemoryAllocationHob->AllocDescriptor.MemoryBaseAddress,
|
|
|
|
MemoryInMmram
|
|
|
|
));
|
|
|
|
CopyMem (
|
|
|
|
MemoryInMmram,
|
|
|
|
(VOID *)(UINTN)MemoryAllocationHob->AllocDescriptor.MemoryBaseAddress,
|
|
|
|
MemoryAllocationHob->AllocDescriptor.MemoryLength
|
|
|
|
);
|
|
|
|
MemoryAllocationHob->AllocDescriptor.MemoryBaseAddress = (EFI_PHYSICAL_ADDRESS)(UINTN)MemoryInMmram;
|
|
|
|
MemoryAllocationHob->AllocDescriptor.MemoryType = EfiRuntimeServicesData;
|
|
|
|
}
|
|
|
|
} else {
|
|
|
|
DEBUG ((
|
|
|
|
DEBUG_ERROR,
|
|
|
|
"Error - Memory Allocation Hob [%08x, %08x] doesn't have a GUID name specified\n",
|
|
|
|
MemoryAllocationHob->AllocDescriptor.MemoryBaseAddress,
|
|
|
|
MemoryAllocationHob->AllocDescriptor.MemoryLength
|
|
|
|
));
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
Hob.Raw = GET_NEXT_HOB (Hob);
|
|
|
|
Hob.Raw = GetNextHob (EFI_HOB_TYPE_MEMORY_ALLOCATION, Hob.Raw);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2024-10-21 11:38:56 +02:00
|
|
|
/**
|
2024-10-21 11:45:56 +02:00
|
|
|
This function is responsible for validating the input HOB list and
|
|
|
|
initializing a new HOB list in MMRAM based on the input HOB list.
|
2020-12-07 12:04:26 +01:00
|
|
|
|
2024-10-21 11:38:56 +02:00
|
|
|
@param [in] HobStart Pointer to the start of the HOB list.
|
2024-10-21 11:45:56 +02:00
|
|
|
@param [in] MmramRanges Pointer to the Mmram ranges.
|
|
|
|
@param [in] MmramRangeCount Count of Mmram ranges.
|
2020-12-07 12:04:26 +01:00
|
|
|
|
2024-10-21 11:38:56 +02:00
|
|
|
@retval Pointer to the new location of hob list in MMRAM.
|
2020-12-07 12:04:26 +01:00
|
|
|
**/
|
2024-10-21 11:38:56 +02:00
|
|
|
VOID *
|
|
|
|
InitializeMmHobList (
|
2024-10-21 11:45:56 +02:00
|
|
|
IN VOID *HobStart,
|
|
|
|
IN EFI_MMRAM_DESCRIPTOR *MmramRanges,
|
|
|
|
IN UINTN MmramRangeCount
|
StandaloneMmPkg/Core: Implementation of Standalone MM Core Module.
Management Mode (MM) is a generic term used to describe a secure
execution environment provided by the CPU and related silicon that is
entered when the CPU detects a MMI. For x86 systems, this can be
implemented with System Management Mode (SMM). For ARM systems, this can
be implemented with TrustZone (TZ).
A MMI can be a CPU instruction or interrupt. Upon detection of a MMI, a
CPU will jump to the MM Entry Point and save some portion of its state
(the "save state") such that execution can be resumed.
The MMI can be generated synchronously by software or asynchronously by
a hardware event. Each MMI source can be detected, cleared and disabled.
Some systems provide for special memory (Management Mode RAM or MMRAM)
which is set aside for software running in MM. Usually the MMRAM is
hidden during normal CPU execution, but this is not required. Usually,
after MMRAM is hidden it cannot be exposed until the next system reset.
The MM Core Interface Specification describes three pieces of the PI
Management Mode architecture:
1. MM Dispatch
During DXE, the DXE Foundation works with the MM Foundation to
schedule MM drivers for execution in the discovered firmware volumes.
2. MM Initialization
MM related code opens MMRAM, creates the MMRAM memory map, and
launches the MM Foundation, which provides the necessary services to
launch MM-related drivers. Then, sometime before boot, MMRAM is
closed and locked. This piece may be completed during the
SEC, PEI or DXE phases.
3. MMI Management
When an MMI generated, the MM environment is created and then the MMI
sources are detected and MMI handlers called.
This patch implements the MM Core.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Sughosh Ganu <sughosh.ganu@arm.com>
Signed-off-by: Supreeth Venkatesh <supreeth.venkatesh@arm.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
2018-07-13 17:05:27 +02:00
|
|
|
)
|
|
|
|
{
|
2024-10-21 11:38:56 +02:00
|
|
|
VOID *MmHobStart;
|
|
|
|
UINTN HobSize;
|
|
|
|
EFI_STATUS Status;
|
StandaloneMmPkg/Core: Implementation of Standalone MM Core Module.
Management Mode (MM) is a generic term used to describe a secure
execution environment provided by the CPU and related silicon that is
entered when the CPU detects a MMI. For x86 systems, this can be
implemented with System Management Mode (SMM). For ARM systems, this can
be implemented with TrustZone (TZ).
A MMI can be a CPU instruction or interrupt. Upon detection of a MMI, a
CPU will jump to the MM Entry Point and save some portion of its state
(the "save state") such that execution can be resumed.
The MMI can be generated synchronously by software or asynchronously by
a hardware event. Each MMI source can be detected, cleared and disabled.
Some systems provide for special memory (Management Mode RAM or MMRAM)
which is set aside for software running in MM. Usually the MMRAM is
hidden during normal CPU execution, but this is not required. Usually,
after MMRAM is hidden it cannot be exposed until the next system reset.
The MM Core Interface Specification describes three pieces of the PI
Management Mode architecture:
1. MM Dispatch
During DXE, the DXE Foundation works with the MM Foundation to
schedule MM drivers for execution in the discovered firmware volumes.
2. MM Initialization
MM related code opens MMRAM, creates the MMRAM memory map, and
launches the MM Foundation, which provides the necessary services to
launch MM-related drivers. Then, sometime before boot, MMRAM is
closed and locked. This piece may be completed during the
SEC, PEI or DXE phases.
3. MMI Management
When an MMI generated, the MM environment is created and then the MMI
sources are detected and MMI handlers called.
This patch implements the MM Core.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Sughosh Ganu <sughosh.ganu@arm.com>
Signed-off-by: Supreeth Venkatesh <supreeth.venkatesh@arm.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
2018-07-13 17:05:27 +02:00
|
|
|
EFI_PEI_HOB_POINTERS Hob;
|
2024-10-21 11:45:56 +02:00
|
|
|
UINTN Index;
|
|
|
|
EFI_PHYSICAL_ADDRESS MmramBase;
|
|
|
|
EFI_PHYSICAL_ADDRESS MmramEnd;
|
|
|
|
EFI_PHYSICAL_ADDRESS ResourceHobBase;
|
|
|
|
EFI_PHYSICAL_ADDRESS ResourceHobEnd;
|
StandaloneMmPkg/Core: Implementation of Standalone MM Core Module.
Management Mode (MM) is a generic term used to describe a secure
execution environment provided by the CPU and related silicon that is
entered when the CPU detects a MMI. For x86 systems, this can be
implemented with System Management Mode (SMM). For ARM systems, this can
be implemented with TrustZone (TZ).
A MMI can be a CPU instruction or interrupt. Upon detection of a MMI, a
CPU will jump to the MM Entry Point and save some portion of its state
(the "save state") such that execution can be resumed.
The MMI can be generated synchronously by software or asynchronously by
a hardware event. Each MMI source can be detected, cleared and disabled.
Some systems provide for special memory (Management Mode RAM or MMRAM)
which is set aside for software running in MM. Usually the MMRAM is
hidden during normal CPU execution, but this is not required. Usually,
after MMRAM is hidden it cannot be exposed until the next system reset.
The MM Core Interface Specification describes three pieces of the PI
Management Mode architecture:
1. MM Dispatch
During DXE, the DXE Foundation works with the MM Foundation to
schedule MM drivers for execution in the discovered firmware volumes.
2. MM Initialization
MM related code opens MMRAM, creates the MMRAM memory map, and
launches the MM Foundation, which provides the necessary services to
launch MM-related drivers. Then, sometime before boot, MMRAM is
closed and locked. This piece may be completed during the
SEC, PEI or DXE phases.
3. MMI Management
When an MMI generated, the MM environment is created and then the MMI
sources are detected and MMI handlers called.
This patch implements the MM Core.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Sughosh Ganu <sughosh.ganu@arm.com>
Signed-off-by: Supreeth Venkatesh <supreeth.venkatesh@arm.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
2018-07-13 17:05:27 +02:00
|
|
|
|
|
|
|
ASSERT (HobStart != NULL);
|
|
|
|
|
|
|
|
Hob.Raw = (UINT8 *)HobStart;
|
|
|
|
while (!END_OF_HOB_LIST (Hob)) {
|
|
|
|
Hob.Raw = GET_NEXT_HOB (Hob);
|
2024-10-21 11:45:56 +02:00
|
|
|
if (Hob.Header->HobType == EFI_HOB_TYPE_RESOURCE_DESCRIPTOR) {
|
|
|
|
ResourceHobBase = Hob.ResourceDescriptor->PhysicalStart;
|
|
|
|
ResourceHobEnd = Hob.ResourceDescriptor->PhysicalStart + Hob.ResourceDescriptor->ResourceLength;
|
|
|
|
|
|
|
|
for (Index = 0; Index < MmramRangeCount; Index++) {
|
|
|
|
MmramBase = MmramRanges[Index].PhysicalStart;
|
|
|
|
MmramEnd = MmramRanges[Index].PhysicalStart + MmramRanges[Index].PhysicalSize;
|
|
|
|
|
|
|
|
if ((MmramBase < ResourceHobEnd) && (MmramEnd > ResourceHobBase)) {
|
|
|
|
//
|
|
|
|
// The Resource HOB is to describe the accessible non-Mmram range.
|
|
|
|
// All Resource HOB should not overlapp with any Mmram range.
|
|
|
|
//
|
|
|
|
DEBUG ((
|
|
|
|
DEBUG_ERROR,
|
|
|
|
"The resource HOB range [0x%lx, 0x%lx] overlaps with MMRAM range\n",
|
|
|
|
ResourceHobBase,
|
|
|
|
ResourceHobEnd
|
|
|
|
));
|
|
|
|
CpuDeadLoop ();
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
StandaloneMmPkg/Core: Implementation of Standalone MM Core Module.
Management Mode (MM) is a generic term used to describe a secure
execution environment provided by the CPU and related silicon that is
entered when the CPU detects a MMI. For x86 systems, this can be
implemented with System Management Mode (SMM). For ARM systems, this can
be implemented with TrustZone (TZ).
A MMI can be a CPU instruction or interrupt. Upon detection of a MMI, a
CPU will jump to the MM Entry Point and save some portion of its state
(the "save state") such that execution can be resumed.
The MMI can be generated synchronously by software or asynchronously by
a hardware event. Each MMI source can be detected, cleared and disabled.
Some systems provide for special memory (Management Mode RAM or MMRAM)
which is set aside for software running in MM. Usually the MMRAM is
hidden during normal CPU execution, but this is not required. Usually,
after MMRAM is hidden it cannot be exposed until the next system reset.
The MM Core Interface Specification describes three pieces of the PI
Management Mode architecture:
1. MM Dispatch
During DXE, the DXE Foundation works with the MM Foundation to
schedule MM drivers for execution in the discovered firmware volumes.
2. MM Initialization
MM related code opens MMRAM, creates the MMRAM memory map, and
launches the MM Foundation, which provides the necessary services to
launch MM-related drivers. Then, sometime before boot, MMRAM is
closed and locked. This piece may be completed during the
SEC, PEI or DXE phases.
3. MMI Management
When an MMI generated, the MM environment is created and then the MMI
sources are detected and MMI handlers called.
This patch implements the MM Core.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Sughosh Ganu <sughosh.ganu@arm.com>
Signed-off-by: Supreeth Venkatesh <supreeth.venkatesh@arm.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
2018-07-13 17:05:27 +02:00
|
|
|
}
|
2021-12-05 23:54:16 +01:00
|
|
|
|
StandaloneMmPkg/Core: Implementation of Standalone MM Core Module.
Management Mode (MM) is a generic term used to describe a secure
execution environment provided by the CPU and related silicon that is
entered when the CPU detects a MMI. For x86 systems, this can be
implemented with System Management Mode (SMM). For ARM systems, this can
be implemented with TrustZone (TZ).
A MMI can be a CPU instruction or interrupt. Upon detection of a MMI, a
CPU will jump to the MM Entry Point and save some portion of its state
(the "save state") such that execution can be resumed.
The MMI can be generated synchronously by software or asynchronously by
a hardware event. Each MMI source can be detected, cleared and disabled.
Some systems provide for special memory (Management Mode RAM or MMRAM)
which is set aside for software running in MM. Usually the MMRAM is
hidden during normal CPU execution, but this is not required. Usually,
after MMRAM is hidden it cannot be exposed until the next system reset.
The MM Core Interface Specification describes three pieces of the PI
Management Mode architecture:
1. MM Dispatch
During DXE, the DXE Foundation works with the MM Foundation to
schedule MM drivers for execution in the discovered firmware volumes.
2. MM Initialization
MM related code opens MMRAM, creates the MMRAM memory map, and
launches the MM Foundation, which provides the necessary services to
launch MM-related drivers. Then, sometime before boot, MMRAM is
closed and locked. This piece may be completed during the
SEC, PEI or DXE phases.
3. MMI Management
When an MMI generated, the MM environment is created and then the MMI
sources are detected and MMI handlers called.
This patch implements the MM Core.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Sughosh Ganu <sughosh.ganu@arm.com>
Signed-off-by: Supreeth Venkatesh <supreeth.venkatesh@arm.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
2018-07-13 17:05:27 +02:00
|
|
|
//
|
|
|
|
// Need plus END_OF_HOB_LIST
|
|
|
|
//
|
2024-10-21 11:38:56 +02:00
|
|
|
HobSize = (UINTN)Hob.Raw - (UINTN)HobStart + sizeof (EFI_HOB_GENERIC_HEADER);
|
|
|
|
DEBUG ((DEBUG_INFO, "HobSize - 0x%x\n", HobSize));
|
|
|
|
|
|
|
|
MmHobStart = AllocatePool (HobSize);
|
|
|
|
DEBUG ((DEBUG_INFO, "MmHobStart - 0x%x\n", MmHobStart));
|
|
|
|
ASSERT (MmHobStart != NULL);
|
|
|
|
CopyMem (MmHobStart, HobStart, HobSize);
|
|
|
|
|
|
|
|
DEBUG ((DEBUG_INFO, "MmInstallConfigurationTable For HobList\n"));
|
|
|
|
Status = MmInstallConfigurationTable (&gMmCoreMmst, &gEfiHobListGuid, MmHobStart, HobSize);
|
|
|
|
ASSERT_EFI_ERROR (Status);
|
|
|
|
|
|
|
|
MigrateMemoryAllocationHobs (MmHobStart);
|
|
|
|
|
|
|
|
return MmHobStart;
|
StandaloneMmPkg/Core: Implementation of Standalone MM Core Module.
Management Mode (MM) is a generic term used to describe a secure
execution environment provided by the CPU and related silicon that is
entered when the CPU detects a MMI. For x86 systems, this can be
implemented with System Management Mode (SMM). For ARM systems, this can
be implemented with TrustZone (TZ).
A MMI can be a CPU instruction or interrupt. Upon detection of a MMI, a
CPU will jump to the MM Entry Point and save some portion of its state
(the "save state") such that execution can be resumed.
The MMI can be generated synchronously by software or asynchronously by
a hardware event. Each MMI source can be detected, cleared and disabled.
Some systems provide for special memory (Management Mode RAM or MMRAM)
which is set aside for software running in MM. Usually the MMRAM is
hidden during normal CPU execution, but this is not required. Usually,
after MMRAM is hidden it cannot be exposed until the next system reset.
The MM Core Interface Specification describes three pieces of the PI
Management Mode architecture:
1. MM Dispatch
During DXE, the DXE Foundation works with the MM Foundation to
schedule MM drivers for execution in the discovered firmware volumes.
2. MM Initialization
MM related code opens MMRAM, creates the MMRAM memory map, and
launches the MM Foundation, which provides the necessary services to
launch MM-related drivers. Then, sometime before boot, MMRAM is
closed and locked. This piece may be completed during the
SEC, PEI or DXE phases.
3. MMI Management
When an MMI generated, the MM environment is created and then the MMI
sources are detected and MMI handlers called.
This patch implements the MM Core.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Sughosh Ganu <sughosh.ganu@arm.com>
Signed-off-by: Supreeth Venkatesh <supreeth.venkatesh@arm.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
2018-07-13 17:05:27 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
The Entry Point for MM Core
|
|
|
|
|
|
|
|
Install DXE Protocols and reload MM Core into MMRAM and register MM Core
|
|
|
|
EntryPoint on the MMI vector.
|
|
|
|
|
|
|
|
Note: This function is called for both DXE invocation and MMRAM invocation.
|
|
|
|
|
2020-12-07 12:04:26 +01:00
|
|
|
@param HobStart Pointer to the start of the HOB list.
|
StandaloneMmPkg/Core: Implementation of Standalone MM Core Module.
Management Mode (MM) is a generic term used to describe a secure
execution environment provided by the CPU and related silicon that is
entered when the CPU detects a MMI. For x86 systems, this can be
implemented with System Management Mode (SMM). For ARM systems, this can
be implemented with TrustZone (TZ).
A MMI can be a CPU instruction or interrupt. Upon detection of a MMI, a
CPU will jump to the MM Entry Point and save some portion of its state
(the "save state") such that execution can be resumed.
The MMI can be generated synchronously by software or asynchronously by
a hardware event. Each MMI source can be detected, cleared and disabled.
Some systems provide for special memory (Management Mode RAM or MMRAM)
which is set aside for software running in MM. Usually the MMRAM is
hidden during normal CPU execution, but this is not required. Usually,
after MMRAM is hidden it cannot be exposed until the next system reset.
The MM Core Interface Specification describes three pieces of the PI
Management Mode architecture:
1. MM Dispatch
During DXE, the DXE Foundation works with the MM Foundation to
schedule MM drivers for execution in the discovered firmware volumes.
2. MM Initialization
MM related code opens MMRAM, creates the MMRAM memory map, and
launches the MM Foundation, which provides the necessary services to
launch MM-related drivers. Then, sometime before boot, MMRAM is
closed and locked. This piece may be completed during the
SEC, PEI or DXE phases.
3. MMI Management
When an MMI generated, the MM environment is created and then the MMI
sources are detected and MMI handlers called.
This patch implements the MM Core.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Sughosh Ganu <sughosh.ganu@arm.com>
Signed-off-by: Supreeth Venkatesh <supreeth.venkatesh@arm.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
2018-07-13 17:05:27 +02:00
|
|
|
|
2020-12-07 12:04:26 +01:00
|
|
|
@retval EFI_SUCCESS Success.
|
|
|
|
@retval EFI_UNSUPPORTED Unsupported operation.
|
StandaloneMmPkg/Core: Implementation of Standalone MM Core Module.
Management Mode (MM) is a generic term used to describe a secure
execution environment provided by the CPU and related silicon that is
entered when the CPU detects a MMI. For x86 systems, this can be
implemented with System Management Mode (SMM). For ARM systems, this can
be implemented with TrustZone (TZ).
A MMI can be a CPU instruction or interrupt. Upon detection of a MMI, a
CPU will jump to the MM Entry Point and save some portion of its state
(the "save state") such that execution can be resumed.
The MMI can be generated synchronously by software or asynchronously by
a hardware event. Each MMI source can be detected, cleared and disabled.
Some systems provide for special memory (Management Mode RAM or MMRAM)
which is set aside for software running in MM. Usually the MMRAM is
hidden during normal CPU execution, but this is not required. Usually,
after MMRAM is hidden it cannot be exposed until the next system reset.
The MM Core Interface Specification describes three pieces of the PI
Management Mode architecture:
1. MM Dispatch
During DXE, the DXE Foundation works with the MM Foundation to
schedule MM drivers for execution in the discovered firmware volumes.
2. MM Initialization
MM related code opens MMRAM, creates the MMRAM memory map, and
launches the MM Foundation, which provides the necessary services to
launch MM-related drivers. Then, sometime before boot, MMRAM is
closed and locked. This piece may be completed during the
SEC, PEI or DXE phases.
3. MMI Management
When an MMI generated, the MM environment is created and then the MMI
sources are detected and MMI handlers called.
This patch implements the MM Core.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Sughosh Ganu <sughosh.ganu@arm.com>
Signed-off-by: Supreeth Venkatesh <supreeth.venkatesh@arm.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
2018-07-13 17:05:27 +02:00
|
|
|
**/
|
|
|
|
EFI_STATUS
|
|
|
|
EFIAPI
|
|
|
|
StandaloneMmMain (
|
|
|
|
IN VOID *HobStart
|
|
|
|
)
|
|
|
|
{
|
|
|
|
EFI_STATUS Status;
|
|
|
|
UINTN Index;
|
|
|
|
VOID *Registration;
|
|
|
|
EFI_HOB_GUID_TYPE *MmramRangesHob;
|
|
|
|
EFI_MMRAM_HOB_DESCRIPTOR_BLOCK *MmramRangesHobData;
|
|
|
|
EFI_MMRAM_DESCRIPTOR *MmramRanges;
|
2021-02-11 02:04:20 +01:00
|
|
|
UINTN MmramRangeCount;
|
StandaloneMmPkg/Core: Implementation of Standalone MM Core Module.
Management Mode (MM) is a generic term used to describe a secure
execution environment provided by the CPU and related silicon that is
entered when the CPU detects a MMI. For x86 systems, this can be
implemented with System Management Mode (SMM). For ARM systems, this can
be implemented with TrustZone (TZ).
A MMI can be a CPU instruction or interrupt. Upon detection of a MMI, a
CPU will jump to the MM Entry Point and save some portion of its state
(the "save state") such that execution can be resumed.
The MMI can be generated synchronously by software or asynchronously by
a hardware event. Each MMI source can be detected, cleared and disabled.
Some systems provide for special memory (Management Mode RAM or MMRAM)
which is set aside for software running in MM. Usually the MMRAM is
hidden during normal CPU execution, but this is not required. Usually,
after MMRAM is hidden it cannot be exposed until the next system reset.
The MM Core Interface Specification describes three pieces of the PI
Management Mode architecture:
1. MM Dispatch
During DXE, the DXE Foundation works with the MM Foundation to
schedule MM drivers for execution in the discovered firmware volumes.
2. MM Initialization
MM related code opens MMRAM, creates the MMRAM memory map, and
launches the MM Foundation, which provides the necessary services to
launch MM-related drivers. Then, sometime before boot, MMRAM is
closed and locked. This piece may be completed during the
SEC, PEI or DXE phases.
3. MMI Management
When an MMI generated, the MM environment is created and then the MMI
sources are detected and MMI handlers called.
This patch implements the MM Core.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Sughosh Ganu <sughosh.ganu@arm.com>
Signed-off-by: Supreeth Venkatesh <supreeth.venkatesh@arm.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
2018-07-13 17:05:27 +02:00
|
|
|
EFI_HOB_FIRMWARE_VOLUME *BfvHob;
|
|
|
|
|
|
|
|
ProcessLibraryConstructorList (HobStart, &gMmCoreMmst);
|
|
|
|
|
|
|
|
DEBUG ((DEBUG_INFO, "MmMain - 0x%x\n", HobStart));
|
|
|
|
|
2024-05-21 05:46:20 +02:00
|
|
|
DEBUG_CODE (
|
|
|
|
PrintHobList (HobStart, NULL);
|
|
|
|
);
|
|
|
|
|
StandaloneMmPkg/Core: Implementation of Standalone MM Core Module.
Management Mode (MM) is a generic term used to describe a secure
execution environment provided by the CPU and related silicon that is
entered when the CPU detects a MMI. For x86 systems, this can be
implemented with System Management Mode (SMM). For ARM systems, this can
be implemented with TrustZone (TZ).
A MMI can be a CPU instruction or interrupt. Upon detection of a MMI, a
CPU will jump to the MM Entry Point and save some portion of its state
(the "save state") such that execution can be resumed.
The MMI can be generated synchronously by software or asynchronously by
a hardware event. Each MMI source can be detected, cleared and disabled.
Some systems provide for special memory (Management Mode RAM or MMRAM)
which is set aside for software running in MM. Usually the MMRAM is
hidden during normal CPU execution, but this is not required. Usually,
after MMRAM is hidden it cannot be exposed until the next system reset.
The MM Core Interface Specification describes three pieces of the PI
Management Mode architecture:
1. MM Dispatch
During DXE, the DXE Foundation works with the MM Foundation to
schedule MM drivers for execution in the discovered firmware volumes.
2. MM Initialization
MM related code opens MMRAM, creates the MMRAM memory map, and
launches the MM Foundation, which provides the necessary services to
launch MM-related drivers. Then, sometime before boot, MMRAM is
closed and locked. This piece may be completed during the
SEC, PEI or DXE phases.
3. MMI Management
When an MMI generated, the MM environment is created and then the MMI
sources are detected and MMI handlers called.
This patch implements the MM Core.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Sughosh Ganu <sughosh.ganu@arm.com>
Signed-off-by: Supreeth Venkatesh <supreeth.venkatesh@arm.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
2018-07-13 17:05:27 +02:00
|
|
|
//
|
2024-05-13 18:56:58 +02:00
|
|
|
// Extract the MMRAM ranges from the MMRAM descriptor HOB
|
StandaloneMmPkg/Core: Implementation of Standalone MM Core Module.
Management Mode (MM) is a generic term used to describe a secure
execution environment provided by the CPU and related silicon that is
entered when the CPU detects a MMI. For x86 systems, this can be
implemented with System Management Mode (SMM). For ARM systems, this can
be implemented with TrustZone (TZ).
A MMI can be a CPU instruction or interrupt. Upon detection of a MMI, a
CPU will jump to the MM Entry Point and save some portion of its state
(the "save state") such that execution can be resumed.
The MMI can be generated synchronously by software or asynchronously by
a hardware event. Each MMI source can be detected, cleared and disabled.
Some systems provide for special memory (Management Mode RAM or MMRAM)
which is set aside for software running in MM. Usually the MMRAM is
hidden during normal CPU execution, but this is not required. Usually,
after MMRAM is hidden it cannot be exposed until the next system reset.
The MM Core Interface Specification describes three pieces of the PI
Management Mode architecture:
1. MM Dispatch
During DXE, the DXE Foundation works with the MM Foundation to
schedule MM drivers for execution in the discovered firmware volumes.
2. MM Initialization
MM related code opens MMRAM, creates the MMRAM memory map, and
launches the MM Foundation, which provides the necessary services to
launch MM-related drivers. Then, sometime before boot, MMRAM is
closed and locked. This piece may be completed during the
SEC, PEI or DXE phases.
3. MMI Management
When an MMI generated, the MM environment is created and then the MMI
sources are detected and MMI handlers called.
This patch implements the MM Core.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Sughosh Ganu <sughosh.ganu@arm.com>
Signed-off-by: Supreeth Venkatesh <supreeth.venkatesh@arm.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
2018-07-13 17:05:27 +02:00
|
|
|
//
|
2024-05-13 20:54:44 +02:00
|
|
|
MmramRangesHob = GetNextGuidHob (&gEfiSmmSmramMemoryGuid, HobStart);
|
2024-05-13 18:56:58 +02:00
|
|
|
if (MmramRangesHob == NULL) {
|
2024-05-13 20:54:44 +02:00
|
|
|
MmramRangesHob = GetNextGuidHob (&gEfiMmPeiMmramMemoryReserveGuid, HobStart);
|
|
|
|
if (MmramRangesHob == NULL) {
|
|
|
|
return EFI_UNSUPPORTED;
|
|
|
|
}
|
StandaloneMmPkg/Core: Implementation of Standalone MM Core Module.
Management Mode (MM) is a generic term used to describe a secure
execution environment provided by the CPU and related silicon that is
entered when the CPU detects a MMI. For x86 systems, this can be
implemented with System Management Mode (SMM). For ARM systems, this can
be implemented with TrustZone (TZ).
A MMI can be a CPU instruction or interrupt. Upon detection of a MMI, a
CPU will jump to the MM Entry Point and save some portion of its state
(the "save state") such that execution can be resumed.
The MMI can be generated synchronously by software or asynchronously by
a hardware event. Each MMI source can be detected, cleared and disabled.
Some systems provide for special memory (Management Mode RAM or MMRAM)
which is set aside for software running in MM. Usually the MMRAM is
hidden during normal CPU execution, but this is not required. Usually,
after MMRAM is hidden it cannot be exposed until the next system reset.
The MM Core Interface Specification describes three pieces of the PI
Management Mode architecture:
1. MM Dispatch
During DXE, the DXE Foundation works with the MM Foundation to
schedule MM drivers for execution in the discovered firmware volumes.
2. MM Initialization
MM related code opens MMRAM, creates the MMRAM memory map, and
launches the MM Foundation, which provides the necessary services to
launch MM-related drivers. Then, sometime before boot, MMRAM is
closed and locked. This piece may be completed during the
SEC, PEI or DXE phases.
3. MMI Management
When an MMI generated, the MM environment is created and then the MMI
sources are detected and MMI handlers called.
This patch implements the MM Core.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Sughosh Ganu <sughosh.ganu@arm.com>
Signed-off-by: Supreeth Venkatesh <supreeth.venkatesh@arm.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
2018-07-13 17:05:27 +02:00
|
|
|
}
|
|
|
|
|
2024-05-13 18:56:58 +02:00
|
|
|
MmramRangesHobData = GET_GUID_HOB_DATA (MmramRangesHob);
|
|
|
|
ASSERT (MmramRangesHobData != NULL);
|
|
|
|
MmramRanges = MmramRangesHobData->Descriptor;
|
|
|
|
MmramRangeCount = (UINTN)MmramRangesHobData->NumberOfMmReservedRegions;
|
|
|
|
ASSERT (MmramRanges);
|
|
|
|
ASSERT (MmramRangeCount);
|
|
|
|
|
StandaloneMmPkg/Core: Implementation of Standalone MM Core Module.
Management Mode (MM) is a generic term used to describe a secure
execution environment provided by the CPU and related silicon that is
entered when the CPU detects a MMI. For x86 systems, this can be
implemented with System Management Mode (SMM). For ARM systems, this can
be implemented with TrustZone (TZ).
A MMI can be a CPU instruction or interrupt. Upon detection of a MMI, a
CPU will jump to the MM Entry Point and save some portion of its state
(the "save state") such that execution can be resumed.
The MMI can be generated synchronously by software or asynchronously by
a hardware event. Each MMI source can be detected, cleared and disabled.
Some systems provide for special memory (Management Mode RAM or MMRAM)
which is set aside for software running in MM. Usually the MMRAM is
hidden during normal CPU execution, but this is not required. Usually,
after MMRAM is hidden it cannot be exposed until the next system reset.
The MM Core Interface Specification describes three pieces of the PI
Management Mode architecture:
1. MM Dispatch
During DXE, the DXE Foundation works with the MM Foundation to
schedule MM drivers for execution in the discovered firmware volumes.
2. MM Initialization
MM related code opens MMRAM, creates the MMRAM memory map, and
launches the MM Foundation, which provides the necessary services to
launch MM-related drivers. Then, sometime before boot, MMRAM is
closed and locked. This piece may be completed during the
SEC, PEI or DXE phases.
3. MMI Management
When an MMI generated, the MM environment is created and then the MMI
sources are detected and MMI handlers called.
This patch implements the MM Core.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Sughosh Ganu <sughosh.ganu@arm.com>
Signed-off-by: Supreeth Venkatesh <supreeth.venkatesh@arm.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
2018-07-13 17:05:27 +02:00
|
|
|
//
|
|
|
|
// Print the MMRAM ranges passed by the caller
|
|
|
|
//
|
|
|
|
DEBUG ((DEBUG_INFO, "MmramRangeCount - 0x%x\n", MmramRangeCount));
|
|
|
|
for (Index = 0; Index < MmramRangeCount; Index++) {
|
|
|
|
DEBUG ((
|
|
|
|
DEBUG_INFO,
|
|
|
|
"MmramRanges[%d]: 0x%016lx - 0x%lx\n",
|
|
|
|
Index,
|
|
|
|
MmramRanges[Index].CpuStart,
|
|
|
|
MmramRanges[Index].PhysicalSize
|
|
|
|
));
|
|
|
|
}
|
|
|
|
|
|
|
|
//
|
|
|
|
// No need to initialize memory service.
|
2020-12-03 13:30:25 +01:00
|
|
|
// It is done in the constructor of StandaloneMmCoreMemoryAllocationLib(),
|
|
|
|
// so that the library linked with StandaloneMmCore can use AllocatePool() in
|
|
|
|
// the constructor.
|
2024-10-21 11:38:56 +02:00
|
|
|
//
|
StandaloneMmPkg/Core: Implementation of Standalone MM Core Module.
Management Mode (MM) is a generic term used to describe a secure
execution environment provided by the CPU and related silicon that is
entered when the CPU detects a MMI. For x86 systems, this can be
implemented with System Management Mode (SMM). For ARM systems, this can
be implemented with TrustZone (TZ).
A MMI can be a CPU instruction or interrupt. Upon detection of a MMI, a
CPU will jump to the MM Entry Point and save some portion of its state
(the "save state") such that execution can be resumed.
The MMI can be generated synchronously by software or asynchronously by
a hardware event. Each MMI source can be detected, cleared and disabled.
Some systems provide for special memory (Management Mode RAM or MMRAM)
which is set aside for software running in MM. Usually the MMRAM is
hidden during normal CPU execution, but this is not required. Usually,
after MMRAM is hidden it cannot be exposed until the next system reset.
The MM Core Interface Specification describes three pieces of the PI
Management Mode architecture:
1. MM Dispatch
During DXE, the DXE Foundation works with the MM Foundation to
schedule MM drivers for execution in the discovered firmware volumes.
2. MM Initialization
MM related code opens MMRAM, creates the MMRAM memory map, and
launches the MM Foundation, which provides the necessary services to
launch MM-related drivers. Then, sometime before boot, MMRAM is
closed and locked. This piece may be completed during the
SEC, PEI or DXE phases.
3. MMI Management
When an MMI generated, the MM environment is created and then the MMI
sources are detected and MMI handlers called.
This patch implements the MM Core.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Sughosh Ganu <sughosh.ganu@arm.com>
Signed-off-by: Supreeth Venkatesh <supreeth.venkatesh@arm.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
2018-07-13 17:05:27 +02:00
|
|
|
//
|
|
|
|
// Install HobList
|
|
|
|
//
|
2024-10-21 11:45:56 +02:00
|
|
|
gHobList = InitializeMmHobList (HobStart, MmramRanges, MmramRangeCount);
|
StandaloneMmPkg/Core: Implementation of Standalone MM Core Module.
Management Mode (MM) is a generic term used to describe a secure
execution environment provided by the CPU and related silicon that is
entered when the CPU detects a MMI. For x86 systems, this can be
implemented with System Management Mode (SMM). For ARM systems, this can
be implemented with TrustZone (TZ).
A MMI can be a CPU instruction or interrupt. Upon detection of a MMI, a
CPU will jump to the MM Entry Point and save some portion of its state
(the "save state") such that execution can be resumed.
The MMI can be generated synchronously by software or asynchronously by
a hardware event. Each MMI source can be detected, cleared and disabled.
Some systems provide for special memory (Management Mode RAM or MMRAM)
which is set aside for software running in MM. Usually the MMRAM is
hidden during normal CPU execution, but this is not required. Usually,
after MMRAM is hidden it cannot be exposed until the next system reset.
The MM Core Interface Specification describes three pieces of the PI
Management Mode architecture:
1. MM Dispatch
During DXE, the DXE Foundation works with the MM Foundation to
schedule MM drivers for execution in the discovered firmware volumes.
2. MM Initialization
MM related code opens MMRAM, creates the MMRAM memory map, and
launches the MM Foundation, which provides the necessary services to
launch MM-related drivers. Then, sometime before boot, MMRAM is
closed and locked. This piece may be completed during the
SEC, PEI or DXE phases.
3. MMI Management
When an MMI generated, the MM environment is created and then the MMI
sources are detected and MMI handlers called.
This patch implements the MM Core.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Sughosh Ganu <sughosh.ganu@arm.com>
Signed-off-by: Supreeth Venkatesh <supreeth.venkatesh@arm.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
2018-07-13 17:05:27 +02:00
|
|
|
|
|
|
|
//
|
|
|
|
// Register notification for EFI_MM_CONFIGURATION_PROTOCOL registration and
|
|
|
|
// use it to register the MM Foundation entrypoint
|
|
|
|
//
|
|
|
|
DEBUG ((DEBUG_INFO, "MmRegisterProtocolNotify - MmConfigurationMmProtocol\n"));
|
|
|
|
Status = MmRegisterProtocolNotify (
|
|
|
|
&gEfiMmConfigurationProtocolGuid,
|
|
|
|
MmConfigurationMmNotify,
|
|
|
|
&Registration
|
|
|
|
);
|
|
|
|
ASSERT_EFI_ERROR (Status);
|
|
|
|
|
|
|
|
//
|
2024-05-13 18:56:58 +02:00
|
|
|
// Get Boot Firmware Volume address from the BFV Hob
|
StandaloneMmPkg/Core: Implementation of Standalone MM Core Module.
Management Mode (MM) is a generic term used to describe a secure
execution environment provided by the CPU and related silicon that is
entered when the CPU detects a MMI. For x86 systems, this can be
implemented with System Management Mode (SMM). For ARM systems, this can
be implemented with TrustZone (TZ).
A MMI can be a CPU instruction or interrupt. Upon detection of a MMI, a
CPU will jump to the MM Entry Point and save some portion of its state
(the "save state") such that execution can be resumed.
The MMI can be generated synchronously by software or asynchronously by
a hardware event. Each MMI source can be detected, cleared and disabled.
Some systems provide for special memory (Management Mode RAM or MMRAM)
which is set aside for software running in MM. Usually the MMRAM is
hidden during normal CPU execution, but this is not required. Usually,
after MMRAM is hidden it cannot be exposed until the next system reset.
The MM Core Interface Specification describes three pieces of the PI
Management Mode architecture:
1. MM Dispatch
During DXE, the DXE Foundation works with the MM Foundation to
schedule MM drivers for execution in the discovered firmware volumes.
2. MM Initialization
MM related code opens MMRAM, creates the MMRAM memory map, and
launches the MM Foundation, which provides the necessary services to
launch MM-related drivers. Then, sometime before boot, MMRAM is
closed and locked. This piece may be completed during the
SEC, PEI or DXE phases.
3. MMI Management
When an MMI generated, the MM environment is created and then the MMI
sources are detected and MMI handlers called.
This patch implements the MM Core.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Sughosh Ganu <sughosh.ganu@arm.com>
Signed-off-by: Supreeth Venkatesh <supreeth.venkatesh@arm.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
2018-07-13 17:05:27 +02:00
|
|
|
//
|
2024-05-13 18:56:58 +02:00
|
|
|
BfvHob = GetFirstHob (EFI_HOB_TYPE_FV);
|
|
|
|
if (BfvHob != NULL) {
|
|
|
|
DEBUG ((DEBUG_INFO, "BFV address - 0x%x\n", BfvHob->BaseAddress));
|
|
|
|
DEBUG ((DEBUG_INFO, "BFV size - 0x%x\n", BfvHob->Length));
|
|
|
|
//
|
|
|
|
// Dispatch standalone BFV
|
|
|
|
//
|
|
|
|
if (BfvHob->BaseAddress != 0) {
|
2024-10-21 04:13:54 +02:00
|
|
|
//
|
|
|
|
// Shadow standalone BFV into MMRAM
|
|
|
|
//
|
|
|
|
mBfv = AllocatePool (BfvHob->Length);
|
|
|
|
if (mBfv != NULL) {
|
|
|
|
CopyMem ((VOID *)mBfv, (VOID *)(UINTN)BfvHob->BaseAddress, BfvHob->Length);
|
|
|
|
DEBUG ((DEBUG_INFO, "Mm Dispatch StandaloneBfvAddress - 0x%08x\n", mBfv));
|
|
|
|
MmCoreFfsFindMmDriver (mBfv, 0);
|
|
|
|
MmDispatcher ();
|
|
|
|
if (!FeaturePcdGet (PcdRestartMmDispatcherOnceMmEntryRegistered)) {
|
|
|
|
FreePool (mBfv);
|
|
|
|
}
|
|
|
|
}
|
2024-05-13 18:56:58 +02:00
|
|
|
}
|
StandaloneMmPkg/Core: Implementation of Standalone MM Core Module.
Management Mode (MM) is a generic term used to describe a secure
execution environment provided by the CPU and related silicon that is
entered when the CPU detects a MMI. For x86 systems, this can be
implemented with System Management Mode (SMM). For ARM systems, this can
be implemented with TrustZone (TZ).
A MMI can be a CPU instruction or interrupt. Upon detection of a MMI, a
CPU will jump to the MM Entry Point and save some portion of its state
(the "save state") such that execution can be resumed.
The MMI can be generated synchronously by software or asynchronously by
a hardware event. Each MMI source can be detected, cleared and disabled.
Some systems provide for special memory (Management Mode RAM or MMRAM)
which is set aside for software running in MM. Usually the MMRAM is
hidden during normal CPU execution, but this is not required. Usually,
after MMRAM is hidden it cannot be exposed until the next system reset.
The MM Core Interface Specification describes three pieces of the PI
Management Mode architecture:
1. MM Dispatch
During DXE, the DXE Foundation works with the MM Foundation to
schedule MM drivers for execution in the discovered firmware volumes.
2. MM Initialization
MM related code opens MMRAM, creates the MMRAM memory map, and
launches the MM Foundation, which provides the necessary services to
launch MM-related drivers. Then, sometime before boot, MMRAM is
closed and locked. This piece may be completed during the
SEC, PEI or DXE phases.
3. MMI Management
When an MMI generated, the MM environment is created and then the MMI
sources are detected and MMI handlers called.
This patch implements the MM Core.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Sughosh Ganu <sughosh.ganu@arm.com>
Signed-off-by: Supreeth Venkatesh <supreeth.venkatesh@arm.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
2018-07-13 17:05:27 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
//
|
|
|
|
// Register all handlers in the core table
|
|
|
|
//
|
|
|
|
for (Index = 0; mMmCoreMmiHandlers[Index].HandlerType != NULL; Index++) {
|
|
|
|
Status = MmiHandlerRegister (
|
|
|
|
mMmCoreMmiHandlers[Index].Handler,
|
|
|
|
mMmCoreMmiHandlers[Index].HandlerType,
|
|
|
|
&mMmCoreMmiHandlers[Index].DispatchHandle
|
|
|
|
);
|
|
|
|
DEBUG ((DEBUG_INFO, "MmiHandlerRegister - GUID %g - Status %d\n", mMmCoreMmiHandlers[Index].HandlerType, Status));
|
|
|
|
}
|
|
|
|
|
2024-05-13 17:51:45 +02:00
|
|
|
MmCorePrepareCommunicationBuffer ();
|
|
|
|
|
2024-05-06 19:59:46 +02:00
|
|
|
//
|
|
|
|
// Install Loaded Image Protocol form MM Core
|
|
|
|
//
|
|
|
|
MmCoreInstallLoadedImage ();
|
|
|
|
|
StandaloneMmPkg/Core: Implementation of Standalone MM Core Module.
Management Mode (MM) is a generic term used to describe a secure
execution environment provided by the CPU and related silicon that is
entered when the CPU detects a MMI. For x86 systems, this can be
implemented with System Management Mode (SMM). For ARM systems, this can
be implemented with TrustZone (TZ).
A MMI can be a CPU instruction or interrupt. Upon detection of a MMI, a
CPU will jump to the MM Entry Point and save some portion of its state
(the "save state") such that execution can be resumed.
The MMI can be generated synchronously by software or asynchronously by
a hardware event. Each MMI source can be detected, cleared and disabled.
Some systems provide for special memory (Management Mode RAM or MMRAM)
which is set aside for software running in MM. Usually the MMRAM is
hidden during normal CPU execution, but this is not required. Usually,
after MMRAM is hidden it cannot be exposed until the next system reset.
The MM Core Interface Specification describes three pieces of the PI
Management Mode architecture:
1. MM Dispatch
During DXE, the DXE Foundation works with the MM Foundation to
schedule MM drivers for execution in the discovered firmware volumes.
2. MM Initialization
MM related code opens MMRAM, creates the MMRAM memory map, and
launches the MM Foundation, which provides the necessary services to
launch MM-related drivers. Then, sometime before boot, MMRAM is
closed and locked. This piece may be completed during the
SEC, PEI or DXE phases.
3. MMI Management
When an MMI generated, the MM environment is created and then the MMI
sources are detected and MMI handlers called.
This patch implements the MM Core.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Sughosh Ganu <sughosh.ganu@arm.com>
Signed-off-by: Supreeth Venkatesh <supreeth.venkatesh@arm.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
2018-07-13 17:05:27 +02:00
|
|
|
DEBUG ((DEBUG_INFO, "MmMain Done!\n"));
|
|
|
|
|
|
|
|
return EFI_SUCCESS;
|
|
|
|
}
|