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 Memory page management functions.
|
|
|
|
|
|
|
|
Copyright (c) 2009 - 2014, Intel Corporation. All rights reserved.<BR>
|
|
|
|
Copyright (c) 2016 - 2018, 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"
|
|
|
|
|
|
|
|
#define TRUNCATE_TO_PAGES(a) ((a) >> EFI_PAGE_SHIFT)
|
|
|
|
|
|
|
|
LIST_ENTRY mMmMemoryMap = INITIALIZE_LIST_HEAD_VARIABLE (mMmMemoryMap);
|
|
|
|
|
|
|
|
UINTN mMapKey;
|
|
|
|
|
2024-05-14 03:46:15 +02:00
|
|
|
//
|
|
|
|
// For GetMemoryMap()
|
|
|
|
//
|
|
|
|
|
|
|
|
#define MEMORY_MAP_SIGNATURE SIGNATURE_32('m','m','a','p')
|
|
|
|
typedef struct {
|
|
|
|
UINTN Signature;
|
|
|
|
LIST_ENTRY Link;
|
|
|
|
|
|
|
|
BOOLEAN FromStack;
|
|
|
|
EFI_MEMORY_TYPE Type;
|
|
|
|
UINT64 Start;
|
|
|
|
UINT64 End;
|
|
|
|
} MEMORY_MAP;
|
|
|
|
|
|
|
|
LIST_ENTRY gMemoryMap = INITIALIZE_LIST_HEAD_VARIABLE (gMemoryMap);
|
|
|
|
|
|
|
|
#define MAX_MAP_DEPTH 6
|
|
|
|
|
|
|
|
///
|
|
|
|
/// mMapDepth - depth of new descriptor stack
|
|
|
|
///
|
|
|
|
UINTN mMapDepth = 0;
|
|
|
|
///
|
|
|
|
/// mMapStack - space to use as temp storage to build new map descriptors
|
|
|
|
///
|
|
|
|
MEMORY_MAP mMapStack[MAX_MAP_DEPTH];
|
|
|
|
UINTN mFreeMapStack = 0;
|
|
|
|
///
|
|
|
|
/// This list maintain the free memory map list
|
|
|
|
///
|
|
|
|
LIST_ENTRY mFreeMemoryMapEntryList = INITIALIZE_LIST_HEAD_VARIABLE (mFreeMemoryMapEntryList);
|
|
|
|
|
|
|
|
/**
|
|
|
|
Allocates pages from the memory map.
|
|
|
|
|
|
|
|
@param[in] Type The type of allocation to perform.
|
|
|
|
@param[in] MemoryType The type of memory to turn the allocated pages
|
|
|
|
into.
|
|
|
|
@param[in] NumberOfPages The number of pages to allocate.
|
|
|
|
@param[out] Memory A pointer to receive the base allocated memory
|
|
|
|
address.
|
|
|
|
@param[in] AddRegion If this memory is new added region.
|
|
|
|
|
|
|
|
@retval EFI_INVALID_PARAMETER Parameters violate checking rules defined in spec.
|
|
|
|
@retval EFI_NOT_FOUND Could not allocate pages match the requirement.
|
|
|
|
@retval EFI_OUT_OF_RESOURCES No enough pages to allocate.
|
|
|
|
@retval EFI_SUCCESS Pages successfully allocated.
|
|
|
|
|
|
|
|
**/
|
|
|
|
EFI_STATUS
|
|
|
|
MmInternalAllocatePagesEx (
|
|
|
|
IN EFI_ALLOCATE_TYPE Type,
|
|
|
|
IN EFI_MEMORY_TYPE MemoryType,
|
|
|
|
IN UINTN NumberOfPages,
|
|
|
|
OUT EFI_PHYSICAL_ADDRESS *Memory,
|
|
|
|
IN BOOLEAN AddRegion
|
|
|
|
);
|
|
|
|
|
|
|
|
/**
|
|
|
|
Internal function. Deque a descriptor entry from the mFreeMemoryMapEntryList.
|
|
|
|
If the list is empty, then allocate a new page to refuel the list.
|
|
|
|
Please Note this algorithm to allocate the memory map descriptor has a property
|
|
|
|
that the memory allocated for memory entries always grows, and will never really be freed.
|
|
|
|
|
|
|
|
@return The Memory map descriptor dequeued from the mFreeMemoryMapEntryList
|
|
|
|
|
|
|
|
**/
|
|
|
|
MEMORY_MAP *
|
|
|
|
AllocateMemoryMapEntry (
|
|
|
|
VOID
|
|
|
|
)
|
|
|
|
{
|
|
|
|
EFI_PHYSICAL_ADDRESS Mem;
|
|
|
|
EFI_STATUS Status;
|
|
|
|
MEMORY_MAP *FreeDescriptorEntries;
|
|
|
|
MEMORY_MAP *Entry;
|
|
|
|
UINTN Index;
|
|
|
|
|
|
|
|
// DEBUG((DEBUG_INFO, "AllocateMemoryMapEntry\n"));
|
|
|
|
|
|
|
|
if (IsListEmpty (&mFreeMemoryMapEntryList)) {
|
|
|
|
// DEBUG((DEBUG_INFO, "mFreeMemoryMapEntryList is empty\n"));
|
|
|
|
//
|
|
|
|
// The list is empty, to allocate one page to refuel the list
|
|
|
|
//
|
|
|
|
Status = MmInternalAllocatePagesEx (
|
|
|
|
AllocateAnyPages,
|
|
|
|
EfiRuntimeServicesData,
|
|
|
|
EFI_SIZE_TO_PAGES (RUNTIME_PAGE_ALLOCATION_GRANULARITY),
|
|
|
|
&Mem,
|
|
|
|
TRUE
|
|
|
|
);
|
|
|
|
ASSERT_EFI_ERROR (Status);
|
|
|
|
if (!EFI_ERROR (Status)) {
|
|
|
|
FreeDescriptorEntries = (MEMORY_MAP *)(UINTN)Mem;
|
|
|
|
// DEBUG((DEBUG_INFO, "New FreeDescriptorEntries - 0x%x\n", FreeDescriptorEntries));
|
|
|
|
//
|
|
|
|
// Enqueue the free memory map entries into the list
|
|
|
|
//
|
|
|
|
for (Index = 0; Index < RUNTIME_PAGE_ALLOCATION_GRANULARITY / sizeof (MEMORY_MAP); Index++) {
|
|
|
|
FreeDescriptorEntries[Index].Signature = MEMORY_MAP_SIGNATURE;
|
|
|
|
InsertTailList (&mFreeMemoryMapEntryList, &FreeDescriptorEntries[Index].Link);
|
|
|
|
}
|
|
|
|
} else {
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
//
|
|
|
|
// dequeue the first descriptor from the list
|
|
|
|
//
|
|
|
|
Entry = CR (mFreeMemoryMapEntryList.ForwardLink, MEMORY_MAP, Link, MEMORY_MAP_SIGNATURE);
|
|
|
|
RemoveEntryList (&Entry->Link);
|
|
|
|
|
|
|
|
return Entry;
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
Internal function. Moves any memory descriptors that are on the
|
|
|
|
temporary descriptor stack to heap.
|
|
|
|
|
|
|
|
**/
|
|
|
|
VOID
|
|
|
|
CoreFreeMemoryMapStack (
|
|
|
|
VOID
|
|
|
|
)
|
|
|
|
{
|
|
|
|
MEMORY_MAP *Entry;
|
|
|
|
|
|
|
|
//
|
|
|
|
// If already freeing the map stack, then return
|
|
|
|
//
|
|
|
|
if (mFreeMapStack != 0) {
|
|
|
|
ASSERT (FALSE);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
//
|
|
|
|
// Move the temporary memory descriptor stack into pool
|
|
|
|
//
|
|
|
|
mFreeMapStack += 1;
|
|
|
|
|
|
|
|
while (mMapDepth != 0) {
|
|
|
|
//
|
|
|
|
// Deque an memory map entry from mFreeMemoryMapEntryList
|
|
|
|
//
|
|
|
|
Entry = AllocateMemoryMapEntry ();
|
|
|
|
ASSERT (Entry);
|
|
|
|
if (Entry == NULL) {
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
//
|
|
|
|
// Update to proper entry
|
|
|
|
//
|
|
|
|
mMapDepth -= 1;
|
|
|
|
|
|
|
|
if (mMapStack[mMapDepth].Link.ForwardLink != NULL) {
|
|
|
|
CopyMem (Entry, &mMapStack[mMapDepth], sizeof (MEMORY_MAP));
|
|
|
|
Entry->FromStack = FALSE;
|
|
|
|
|
|
|
|
//
|
|
|
|
// Move this entry to general memory
|
|
|
|
//
|
|
|
|
InsertTailList (&mMapStack[mMapDepth].Link, &Entry->Link);
|
|
|
|
RemoveEntryList (&mMapStack[mMapDepth].Link);
|
|
|
|
mMapStack[mMapDepth].Link.ForwardLink = NULL;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
mFreeMapStack -= 1;
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
Insert new entry from memory map.
|
|
|
|
|
|
|
|
@param[in] Link The old memory map entry to be linked.
|
|
|
|
@param[in] Start The start address of new memory map entry.
|
|
|
|
@param[in] End The end address of new memory map entry.
|
|
|
|
@param[in] Type The type of new memory map entry.
|
|
|
|
@param[in] Next If new entry is inserted to the next of old entry.
|
|
|
|
@param[in] AddRegion If this memory is new added region.
|
|
|
|
**/
|
|
|
|
VOID
|
|
|
|
InsertNewEntry (
|
|
|
|
IN LIST_ENTRY *Link,
|
|
|
|
IN UINT64 Start,
|
|
|
|
IN UINT64 End,
|
|
|
|
IN EFI_MEMORY_TYPE Type,
|
|
|
|
IN BOOLEAN Next,
|
|
|
|
IN BOOLEAN AddRegion
|
|
|
|
)
|
|
|
|
{
|
|
|
|
MEMORY_MAP *Entry;
|
|
|
|
|
|
|
|
Entry = &mMapStack[mMapDepth];
|
|
|
|
mMapDepth += 1;
|
|
|
|
ASSERT (mMapDepth < MAX_MAP_DEPTH);
|
|
|
|
Entry->FromStack = TRUE;
|
|
|
|
|
|
|
|
Entry->Signature = MEMORY_MAP_SIGNATURE;
|
|
|
|
Entry->Type = Type;
|
|
|
|
Entry->Start = Start;
|
|
|
|
Entry->End = End;
|
|
|
|
if (Next) {
|
|
|
|
InsertHeadList (Link, &Entry->Link);
|
|
|
|
} else {
|
|
|
|
InsertTailList (Link, &Entry->Link);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
Remove old entry from memory map.
|
|
|
|
|
|
|
|
@param[in] Entry Memory map entry to be removed.
|
|
|
|
**/
|
|
|
|
VOID
|
|
|
|
RemoveOldEntry (
|
|
|
|
IN MEMORY_MAP *Entry
|
|
|
|
)
|
|
|
|
{
|
|
|
|
RemoveEntryList (&Entry->Link);
|
|
|
|
Entry->Link.ForwardLink = NULL;
|
|
|
|
|
|
|
|
if (!Entry->FromStack) {
|
|
|
|
InsertTailList (&mFreeMemoryMapEntryList, &Entry->Link);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
Update MM memory map entry.
|
|
|
|
|
|
|
|
@param[in] Type The type of allocation to perform.
|
|
|
|
@param[in] Memory The base of memory address.
|
|
|
|
@param[in] NumberOfPages The number of pages to allocate.
|
|
|
|
@param[in] AddRegion If this memory is new added region.
|
|
|
|
**/
|
|
|
|
VOID
|
|
|
|
ConvertMmMemoryMapEntry (
|
|
|
|
IN EFI_MEMORY_TYPE Type,
|
|
|
|
IN EFI_PHYSICAL_ADDRESS Memory,
|
|
|
|
IN UINTN NumberOfPages,
|
|
|
|
IN BOOLEAN AddRegion
|
|
|
|
)
|
|
|
|
{
|
|
|
|
LIST_ENTRY *Link;
|
|
|
|
MEMORY_MAP *Entry;
|
|
|
|
MEMORY_MAP *NextEntry;
|
|
|
|
LIST_ENTRY *NextLink;
|
|
|
|
MEMORY_MAP *PreviousEntry;
|
|
|
|
LIST_ENTRY *PreviousLink;
|
|
|
|
EFI_PHYSICAL_ADDRESS Start;
|
|
|
|
EFI_PHYSICAL_ADDRESS End;
|
|
|
|
|
|
|
|
Start = Memory;
|
|
|
|
End = Memory + EFI_PAGES_TO_SIZE (NumberOfPages) - 1;
|
|
|
|
|
|
|
|
//
|
|
|
|
// Exclude memory region
|
|
|
|
//
|
|
|
|
Link = gMemoryMap.ForwardLink;
|
|
|
|
while (Link != &gMemoryMap) {
|
|
|
|
Entry = CR (Link, MEMORY_MAP, Link, MEMORY_MAP_SIGNATURE);
|
|
|
|
Link = Link->ForwardLink;
|
|
|
|
|
|
|
|
//
|
|
|
|
// ---------------------------------------------------
|
|
|
|
// | +----------+ +------+ +------+ +------+ |
|
|
|
|
// ---|gMemoryMep|---|Entry1|---|Entry2|---|Entry3|---
|
|
|
|
// +----------+ ^ +------+ +------+ +------+
|
|
|
|
// |
|
|
|
|
// +------+
|
|
|
|
// |EntryX|
|
|
|
|
// +------+
|
|
|
|
//
|
|
|
|
if (Entry->Start > End) {
|
|
|
|
if ((Entry->Start == End + 1) && (Entry->Type == Type)) {
|
|
|
|
Entry->Start = Start;
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
InsertNewEntry (
|
|
|
|
&Entry->Link,
|
|
|
|
Start,
|
|
|
|
End,
|
|
|
|
Type,
|
|
|
|
FALSE,
|
|
|
|
AddRegion
|
|
|
|
);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
if ((Entry->Start <= Start) && (Entry->End >= End)) {
|
|
|
|
if (Entry->Type != Type) {
|
|
|
|
if (Entry->Start < Start) {
|
|
|
|
//
|
|
|
|
// ---------------------------------------------------
|
|
|
|
// | +----------+ +------+ +------+ +------+ |
|
|
|
|
// ---|gMemoryMep|---|Entry1|---|EntryX|---|Entry3|---
|
|
|
|
// +----------+ +------+ ^ +------+ +------+
|
|
|
|
// |
|
|
|
|
// +------+
|
|
|
|
// |EntryA|
|
|
|
|
// +------+
|
|
|
|
//
|
|
|
|
InsertNewEntry (
|
|
|
|
&Entry->Link,
|
|
|
|
Entry->Start,
|
|
|
|
Start - 1,
|
|
|
|
Entry->Type,
|
|
|
|
FALSE,
|
|
|
|
AddRegion
|
|
|
|
);
|
|
|
|
}
|
|
|
|
|
|
|
|
if (Entry->End > End) {
|
|
|
|
//
|
|
|
|
// ---------------------------------------------------
|
|
|
|
// | +----------+ +------+ +------+ +------+ |
|
|
|
|
// ---|gMemoryMep|---|Entry1|---|EntryX|---|Entry3|---
|
|
|
|
// +----------+ +------+ +------+ ^ +------+
|
|
|
|
// |
|
|
|
|
// +------+
|
|
|
|
// |EntryZ|
|
|
|
|
// +------+
|
|
|
|
//
|
|
|
|
InsertNewEntry (
|
|
|
|
&Entry->Link,
|
|
|
|
End + 1,
|
|
|
|
Entry->End,
|
|
|
|
Entry->Type,
|
|
|
|
TRUE,
|
|
|
|
AddRegion
|
|
|
|
);
|
|
|
|
}
|
|
|
|
|
|
|
|
//
|
|
|
|
// Update this node
|
|
|
|
//
|
|
|
|
Entry->Start = Start;
|
|
|
|
Entry->End = End;
|
|
|
|
Entry->Type = Type;
|
|
|
|
|
|
|
|
//
|
|
|
|
// Check adjacent
|
|
|
|
//
|
|
|
|
NextLink = Entry->Link.ForwardLink;
|
|
|
|
if (NextLink != &gMemoryMap) {
|
|
|
|
NextEntry = CR (NextLink, MEMORY_MAP, Link, MEMORY_MAP_SIGNATURE);
|
|
|
|
//
|
|
|
|
// ---------------------------------------------------
|
|
|
|
// | +----------+ +------+ +-----------------+ |
|
|
|
|
// ---|gMemoryMep|---|Entry1|---|EntryX Entry3|---
|
|
|
|
// +----------+ +------+ +-----------------+
|
|
|
|
//
|
|
|
|
if ((Entry->Type == NextEntry->Type) && (Entry->End + 1 == NextEntry->Start)) {
|
|
|
|
Entry->End = NextEntry->End;
|
|
|
|
RemoveOldEntry (NextEntry);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
PreviousLink = Entry->Link.BackLink;
|
|
|
|
if (PreviousLink != &gMemoryMap) {
|
|
|
|
PreviousEntry = CR (PreviousLink, MEMORY_MAP, Link, MEMORY_MAP_SIGNATURE);
|
|
|
|
//
|
|
|
|
// ---------------------------------------------------
|
|
|
|
// | +----------+ +-----------------+ +------+ |
|
|
|
|
// ---|gMemoryMep|---|Entry1 EntryX|---|Entry3|---
|
|
|
|
// +----------+ +-----------------+ +------+
|
|
|
|
//
|
|
|
|
if ((PreviousEntry->Type == Entry->Type) && (PreviousEntry->End + 1 == Entry->Start)) {
|
|
|
|
PreviousEntry->End = Entry->End;
|
|
|
|
RemoveOldEntry (Entry);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
//
|
|
|
|
// ---------------------------------------------------
|
|
|
|
// | +----------+ +------+ +------+ +------+ |
|
|
|
|
// ---|gMemoryMep|---|Entry1|---|Entry2|---|Entry3|---
|
|
|
|
// +----------+ +------+ +------+ +------+ ^
|
|
|
|
// |
|
|
|
|
// +------+
|
|
|
|
// |EntryX|
|
|
|
|
// +------+
|
|
|
|
//
|
|
|
|
Link = gMemoryMap.BackLink;
|
|
|
|
if (Link != &gMemoryMap) {
|
|
|
|
Entry = CR (Link, MEMORY_MAP, Link, MEMORY_MAP_SIGNATURE);
|
|
|
|
if ((Entry->End + 1 == Start) && (Entry->Type == Type)) {
|
|
|
|
Entry->End = End;
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
InsertNewEntry (
|
|
|
|
&gMemoryMap,
|
|
|
|
Start,
|
|
|
|
End,
|
|
|
|
Type,
|
|
|
|
FALSE,
|
|
|
|
AddRegion
|
|
|
|
);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
Return the count of Mm memory map entry.
|
|
|
|
|
|
|
|
@return The count of Mm memory map entry.
|
|
|
|
**/
|
|
|
|
UINTN
|
|
|
|
GetMmMemoryMapEntryCount (
|
|
|
|
VOID
|
|
|
|
)
|
|
|
|
{
|
|
|
|
LIST_ENTRY *Link;
|
|
|
|
UINTN Count;
|
|
|
|
|
|
|
|
Count = 0;
|
|
|
|
Link = gMemoryMap.ForwardLink;
|
|
|
|
while (Link != &gMemoryMap) {
|
|
|
|
Link = Link->ForwardLink;
|
|
|
|
Count++;
|
|
|
|
}
|
|
|
|
|
|
|
|
return Count;
|
|
|
|
}
|
|
|
|
|
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
|
|
|
/**
|
|
|
|
Internal Function. Allocate n pages from given free page node.
|
|
|
|
|
|
|
|
@param Pages The free page node.
|
|
|
|
@param NumberOfPages Number of pages to be allocated.
|
|
|
|
@param MaxAddress Request to allocate memory below this address.
|
|
|
|
|
|
|
|
@return Memory address of allocated pages.
|
|
|
|
|
|
|
|
**/
|
|
|
|
UINTN
|
|
|
|
InternalAllocPagesOnOneNode (
|
|
|
|
IN OUT FREE_PAGE_LIST *Pages,
|
|
|
|
IN UINTN NumberOfPages,
|
|
|
|
IN UINTN MaxAddress
|
|
|
|
)
|
|
|
|
{
|
|
|
|
UINTN Top;
|
|
|
|
UINTN Bottom;
|
|
|
|
FREE_PAGE_LIST *Node;
|
|
|
|
|
|
|
|
Top = TRUNCATE_TO_PAGES (MaxAddress + 1 - (UINTN)Pages);
|
|
|
|
if (Top > Pages->NumberOfPages) {
|
|
|
|
Top = Pages->NumberOfPages;
|
|
|
|
}
|
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
|
|
|
Bottom = Top - NumberOfPages;
|
|
|
|
|
|
|
|
if (Top < Pages->NumberOfPages) {
|
|
|
|
Node = (FREE_PAGE_LIST *)((UINTN)Pages + EFI_PAGES_TO_SIZE (Top));
|
|
|
|
Node->NumberOfPages = Pages->NumberOfPages - Top;
|
|
|
|
InsertHeadList (&Pages->Link, &Node->Link);
|
|
|
|
}
|
|
|
|
|
|
|
|
if (Bottom > 0) {
|
|
|
|
Pages->NumberOfPages = Bottom;
|
|
|
|
} else {
|
|
|
|
RemoveEntryList (&Pages->Link);
|
|
|
|
}
|
|
|
|
|
|
|
|
return (UINTN)Pages + EFI_PAGES_TO_SIZE (Bottom);
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
Internal Function. Allocate n pages from free page list below MaxAddress.
|
|
|
|
|
|
|
|
@param FreePageList The free page node.
|
|
|
|
@param NumberOfPages Number of pages to be allocated.
|
|
|
|
@param MaxAddress Request to allocate memory below this address.
|
|
|
|
|
|
|
|
@return Memory address of allocated pages.
|
|
|
|
|
|
|
|
**/
|
|
|
|
UINTN
|
|
|
|
InternalAllocMaxAddress (
|
|
|
|
IN OUT LIST_ENTRY *FreePageList,
|
|
|
|
IN UINTN NumberOfPages,
|
|
|
|
IN UINTN MaxAddress
|
|
|
|
)
|
|
|
|
{
|
|
|
|
LIST_ENTRY *Node;
|
|
|
|
FREE_PAGE_LIST *Pages;
|
|
|
|
|
|
|
|
for (Node = FreePageList->BackLink; Node != FreePageList; Node = Node->BackLink) {
|
|
|
|
Pages = BASE_CR (Node, FREE_PAGE_LIST, Link);
|
|
|
|
if ((Pages->NumberOfPages >= NumberOfPages) &&
|
|
|
|
((UINTN)Pages + EFI_PAGES_TO_SIZE (NumberOfPages) - 1 <= MaxAddress))
|
|
|
|
{
|
|
|
|
return InternalAllocPagesOnOneNode (Pages, NumberOfPages, MaxAddress);
|
|
|
|
}
|
|
|
|
}
|
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
|
|
|
return (UINTN)(-1);
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
Internal Function. Allocate n pages from free page list at given address.
|
|
|
|
|
|
|
|
@param FreePageList The free page node.
|
|
|
|
@param NumberOfPages Number of pages to be allocated.
|
|
|
|
@param MaxAddress Request to allocate memory below this address.
|
|
|
|
|
|
|
|
@return Memory address of allocated pages.
|
|
|
|
|
|
|
|
**/
|
|
|
|
UINTN
|
|
|
|
InternalAllocAddress (
|
|
|
|
IN OUT LIST_ENTRY *FreePageList,
|
|
|
|
IN UINTN NumberOfPages,
|
|
|
|
IN UINTN Address
|
|
|
|
)
|
|
|
|
{
|
|
|
|
UINTN EndAddress;
|
|
|
|
LIST_ENTRY *Node;
|
|
|
|
FREE_PAGE_LIST *Pages;
|
|
|
|
|
|
|
|
if ((Address & EFI_PAGE_MASK) != 0) {
|
|
|
|
return ~Address;
|
|
|
|
}
|
|
|
|
|
|
|
|
EndAddress = Address + EFI_PAGES_TO_SIZE (NumberOfPages);
|
|
|
|
for (Node = FreePageList->BackLink; Node != FreePageList; Node = Node->BackLink) {
|
|
|
|
Pages = BASE_CR (Node, FREE_PAGE_LIST, Link);
|
|
|
|
if ((UINTN)Pages <= Address) {
|
|
|
|
if ((UINTN)Pages + EFI_PAGES_TO_SIZE (Pages->NumberOfPages) < EndAddress) {
|
|
|
|
break;
|
|
|
|
}
|
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
|
|
|
return InternalAllocPagesOnOneNode (Pages, NumberOfPages, EndAddress);
|
|
|
|
}
|
|
|
|
}
|
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
|
|
|
return ~Address;
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
Allocates pages from the memory map.
|
|
|
|
|
2024-05-14 03:46:15 +02:00
|
|
|
@param[in] Type The type of allocation to perform.
|
|
|
|
@param[in] MemoryType The type of memory to turn the allocated pages
|
|
|
|
into.
|
|
|
|
@param[in] NumberOfPages The number of pages to allocate.
|
|
|
|
@param[out] Memory A pointer to receive the base allocated memory
|
|
|
|
address.
|
|
|
|
@param[in] AddRegion If this memory is new added region.
|
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
|
|
|
|
|
|
|
@retval EFI_INVALID_PARAMETER Parameters violate checking rules defined in spec.
|
|
|
|
@retval EFI_NOT_FOUND Could not allocate pages match the requirement.
|
|
|
|
@retval EFI_OUT_OF_RESOURCES No enough pages to allocate.
|
|
|
|
@retval EFI_SUCCESS Pages successfully allocated.
|
|
|
|
|
|
|
|
**/
|
|
|
|
EFI_STATUS
|
2024-05-14 03:46:15 +02:00
|
|
|
MmInternalAllocatePagesEx (
|
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 EFI_ALLOCATE_TYPE Type,
|
|
|
|
IN EFI_MEMORY_TYPE MemoryType,
|
|
|
|
IN UINTN NumberOfPages,
|
2024-05-14 03:46:15 +02:00
|
|
|
OUT EFI_PHYSICAL_ADDRESS *Memory,
|
|
|
|
IN BOOLEAN AddRegion
|
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
|
|
|
)
|
|
|
|
{
|
|
|
|
UINTN RequestedAddress;
|
|
|
|
|
|
|
|
if ((MemoryType != EfiRuntimeServicesCode) &&
|
|
|
|
(MemoryType != EfiRuntimeServicesData))
|
|
|
|
{
|
|
|
|
return EFI_INVALID_PARAMETER;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (NumberOfPages > TRUNCATE_TO_PAGES ((UINTN)-1) + 1) {
|
|
|
|
return EFI_OUT_OF_RESOURCES;
|
|
|
|
}
|
|
|
|
|
|
|
|
//
|
|
|
|
// We don't track memory type in MM
|
|
|
|
//
|
|
|
|
RequestedAddress = (UINTN)*Memory;
|
|
|
|
switch (Type) {
|
|
|
|
case AllocateAnyPages:
|
|
|
|
RequestedAddress = (UINTN)(-1);
|
|
|
|
case AllocateMaxAddress:
|
|
|
|
*Memory = InternalAllocMaxAddress (
|
|
|
|
&mMmMemoryMap,
|
|
|
|
NumberOfPages,
|
|
|
|
RequestedAddress
|
|
|
|
);
|
|
|
|
if (*Memory == (UINTN)-1) {
|
|
|
|
return EFI_OUT_OF_RESOURCES;
|
|
|
|
}
|
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
|
|
|
break;
|
|
|
|
case AllocateAddress:
|
|
|
|
*Memory = InternalAllocAddress (
|
|
|
|
&mMmMemoryMap,
|
|
|
|
NumberOfPages,
|
|
|
|
RequestedAddress
|
|
|
|
);
|
|
|
|
if (*Memory != RequestedAddress) {
|
|
|
|
return EFI_NOT_FOUND;
|
|
|
|
}
|
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
|
|
|
break;
|
|
|
|
default:
|
|
|
|
return EFI_INVALID_PARAMETER;
|
|
|
|
}
|
2021-12-05 23:54:16 +01:00
|
|
|
|
2024-05-14 03:46:15 +02:00
|
|
|
//
|
|
|
|
// Update MmMemoryMap here.
|
|
|
|
//
|
|
|
|
ConvertMmMemoryMapEntry (MemoryType, *Memory, NumberOfPages, AddRegion);
|
|
|
|
if (!AddRegion) {
|
|
|
|
CoreFreeMemoryMapStack ();
|
|
|
|
}
|
|
|
|
|
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-05-14 03:46:15 +02:00
|
|
|
/**
|
|
|
|
Allocates pages from the memory map.
|
|
|
|
|
|
|
|
@param[in] Type The type of allocation to perform.
|
|
|
|
@param[in] MemoryType The type of memory to turn the allocated pages
|
|
|
|
into.
|
|
|
|
@param[in] NumberOfPages The number of pages to allocate.
|
|
|
|
@param[out] Memory A pointer to receive the base allocated memory
|
|
|
|
address.
|
|
|
|
|
|
|
|
@retval EFI_INVALID_PARAMETER Parameters violate checking rules defined in spec.
|
|
|
|
@retval EFI_NOT_FOUND Could not allocate pages match the requirement.
|
|
|
|
@retval EFI_OUT_OF_RESOURCES No enough pages to allocate.
|
|
|
|
@retval EFI_SUCCESS Pages successfully allocated.
|
|
|
|
|
|
|
|
**/
|
|
|
|
EFI_STATUS
|
|
|
|
EFIAPI
|
|
|
|
MmInternalAllocatePages (
|
|
|
|
IN EFI_ALLOCATE_TYPE Type,
|
|
|
|
IN EFI_MEMORY_TYPE MemoryType,
|
|
|
|
IN UINTN NumberOfPages,
|
|
|
|
OUT EFI_PHYSICAL_ADDRESS *Memory
|
|
|
|
)
|
|
|
|
{
|
|
|
|
return MmInternalAllocatePagesEx (
|
|
|
|
Type,
|
|
|
|
MemoryType,
|
|
|
|
NumberOfPages,
|
|
|
|
Memory,
|
|
|
|
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
|
|
|
/**
|
|
|
|
Allocates pages from the memory map.
|
|
|
|
|
|
|
|
@param Type The type of allocation to perform.
|
|
|
|
@param MemoryType The type of memory to turn the allocated pages
|
|
|
|
into.
|
|
|
|
@param NumberOfPages The number of pages to allocate.
|
|
|
|
@param Memory A pointer to receive the base allocated memory
|
|
|
|
address.
|
|
|
|
|
|
|
|
@retval EFI_INVALID_PARAMETER Parameters violate checking rules defined in spec.
|
|
|
|
@retval EFI_NOT_FOUND Could not allocate pages match the requirement.
|
|
|
|
@retval EFI_OUT_OF_RESOURCES No enough pages to allocate.
|
|
|
|
@retval EFI_SUCCESS Pages successfully allocated.
|
|
|
|
|
|
|
|
**/
|
|
|
|
EFI_STATUS
|
|
|
|
EFIAPI
|
|
|
|
MmAllocatePages (
|
|
|
|
IN EFI_ALLOCATE_TYPE Type,
|
|
|
|
IN EFI_MEMORY_TYPE MemoryType,
|
|
|
|
IN UINTN NumberOfPages,
|
|
|
|
OUT EFI_PHYSICAL_ADDRESS *Memory
|
|
|
|
)
|
|
|
|
{
|
|
|
|
EFI_STATUS Status;
|
|
|
|
|
|
|
|
Status = MmInternalAllocatePages (Type, MemoryType, NumberOfPages, Memory);
|
|
|
|
return Status;
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
Internal Function. Merge two adjacent nodes.
|
|
|
|
|
|
|
|
@param First The first of two nodes to merge.
|
|
|
|
|
|
|
|
@return Pointer to node after merge (if success) or pointer to next node (if fail).
|
|
|
|
|
|
|
|
**/
|
|
|
|
FREE_PAGE_LIST *
|
|
|
|
InternalMergeNodes (
|
|
|
|
IN FREE_PAGE_LIST *First
|
|
|
|
)
|
|
|
|
{
|
|
|
|
FREE_PAGE_LIST *Next;
|
|
|
|
|
|
|
|
Next = BASE_CR (First->Link.ForwardLink, FREE_PAGE_LIST, Link);
|
|
|
|
ASSERT (
|
|
|
|
TRUNCATE_TO_PAGES ((UINTN)Next - (UINTN)First) >= First->NumberOfPages
|
|
|
|
);
|
|
|
|
|
|
|
|
if (TRUNCATE_TO_PAGES ((UINTN)Next - (UINTN)First) == First->NumberOfPages) {
|
|
|
|
First->NumberOfPages += Next->NumberOfPages;
|
|
|
|
RemoveEntryList (&Next->Link);
|
|
|
|
Next = First;
|
|
|
|
}
|
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
|
|
|
return Next;
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
Frees previous allocated pages.
|
|
|
|
|
2024-05-14 03:46:15 +02:00
|
|
|
@param[in] Memory Base address of memory being freed.
|
|
|
|
@param[in] NumberOfPages The number of pages to free.
|
|
|
|
@param[in] AddRegion If this memory is new added region.
|
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
|
|
|
|
|
|
|
@retval EFI_NOT_FOUND Could not find the entry that covers the range.
|
2024-05-14 03:46:15 +02:00
|
|
|
@retval EFI_INVALID_PARAMETER Address not aligned, Address is zero or NumberOfPages is zero.
|
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 Pages successfully freed.
|
|
|
|
|
|
|
|
**/
|
|
|
|
EFI_STATUS
|
2024-05-14 03:46:15 +02:00
|
|
|
MmInternalFreePagesEx (
|
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 EFI_PHYSICAL_ADDRESS Memory,
|
2024-05-14 03:46:15 +02:00
|
|
|
IN UINTN NumberOfPages,
|
|
|
|
IN BOOLEAN AddRegion
|
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
|
|
|
)
|
|
|
|
{
|
|
|
|
LIST_ENTRY *Node;
|
|
|
|
FREE_PAGE_LIST *Pages;
|
|
|
|
|
|
|
|
if ((Memory & EFI_PAGE_MASK) != 0) {
|
|
|
|
return EFI_INVALID_PARAMETER;
|
|
|
|
}
|
|
|
|
|
|
|
|
Pages = NULL;
|
|
|
|
Node = mMmMemoryMap.ForwardLink;
|
|
|
|
while (Node != &mMmMemoryMap) {
|
|
|
|
Pages = BASE_CR (Node, FREE_PAGE_LIST, Link);
|
|
|
|
if (Memory < (UINTN)Pages) {
|
|
|
|
break;
|
|
|
|
}
|
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
|
|
|
Node = Node->ForwardLink;
|
|
|
|
}
|
|
|
|
|
|
|
|
if ((Node != &mMmMemoryMap) &&
|
|
|
|
(Memory + EFI_PAGES_TO_SIZE (NumberOfPages) > (UINTN)Pages))
|
|
|
|
{
|
|
|
|
return EFI_INVALID_PARAMETER;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (Node->BackLink != &mMmMemoryMap) {
|
|
|
|
Pages = BASE_CR (Node->BackLink, FREE_PAGE_LIST, Link);
|
|
|
|
if ((UINTN)Pages + EFI_PAGES_TO_SIZE (Pages->NumberOfPages) > Memory) {
|
|
|
|
return EFI_INVALID_PARAMETER;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
Pages = (FREE_PAGE_LIST *)(UINTN)Memory;
|
|
|
|
Pages->NumberOfPages = NumberOfPages;
|
|
|
|
InsertTailList (Node, &Pages->Link);
|
|
|
|
|
|
|
|
if (Pages->Link.BackLink != &mMmMemoryMap) {
|
|
|
|
Pages = InternalMergeNodes (
|
|
|
|
BASE_CR (Pages->Link.BackLink, FREE_PAGE_LIST, Link)
|
|
|
|
);
|
|
|
|
}
|
|
|
|
|
|
|
|
if (Node != &mMmMemoryMap) {
|
|
|
|
InternalMergeNodes (Pages);
|
|
|
|
}
|
|
|
|
|
2024-05-14 03:46:15 +02:00
|
|
|
//
|
|
|
|
// Update MmMemoryMap here.
|
|
|
|
//
|
|
|
|
ConvertMmMemoryMapEntry (EfiConventionalMemory, Memory, NumberOfPages, AddRegion);
|
|
|
|
if (!AddRegion) {
|
|
|
|
CoreFreeMemoryMapStack ();
|
|
|
|
}
|
|
|
|
|
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-05-14 03:46:15 +02:00
|
|
|
/**
|
|
|
|
Frees previous allocated pages.
|
|
|
|
|
|
|
|
@param[in] Memory Base address of memory being freed.
|
|
|
|
@param[in] NumberOfPages The number of pages to free.
|
|
|
|
|
|
|
|
@retval EFI_NOT_FOUND Could not find the entry that covers the range.
|
|
|
|
@retval EFI_INVALID_PARAMETER Address not aligned, Address is zero or NumberOfPages is zero.
|
|
|
|
@return EFI_SUCCESS Pages successfully freed.
|
|
|
|
|
|
|
|
**/
|
|
|
|
EFI_STATUS
|
|
|
|
EFIAPI
|
|
|
|
MmInternalFreePages (
|
|
|
|
IN EFI_PHYSICAL_ADDRESS Memory,
|
|
|
|
IN UINTN NumberOfPages
|
|
|
|
)
|
|
|
|
{
|
|
|
|
return MmInternalFreePagesEx (Memory, NumberOfPages, 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
|
|
|
/**
|
|
|
|
Frees previous allocated pages.
|
|
|
|
|
|
|
|
@param Memory Base address of memory being freed.
|
|
|
|
@param NumberOfPages The number of pages to free.
|
|
|
|
|
|
|
|
@retval EFI_NOT_FOUND Could not find the entry that covers the range.
|
2024-05-14 03:46:15 +02:00
|
|
|
@retval EFI_INVALID_PARAMETER Address not aligned, Address is zero or NumberOfPages is zero.
|
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 Pages successfully freed.
|
|
|
|
|
|
|
|
**/
|
|
|
|
EFI_STATUS
|
|
|
|
EFIAPI
|
|
|
|
MmFreePages (
|
|
|
|
IN EFI_PHYSICAL_ADDRESS Memory,
|
|
|
|
IN UINTN NumberOfPages
|
|
|
|
)
|
|
|
|
{
|
|
|
|
EFI_STATUS Status;
|
|
|
|
|
|
|
|
Status = MmInternalFreePages (Memory, NumberOfPages);
|
|
|
|
return Status;
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
Add free MMRAM region for use by memory service.
|
|
|
|
|
|
|
|
@param MemBase Base address of memory region.
|
|
|
|
@param MemLength Length of the memory region.
|
|
|
|
@param Type Memory type.
|
|
|
|
@param Attributes Memory region state.
|
|
|
|
|
|
|
|
**/
|
|
|
|
VOID
|
|
|
|
MmAddMemoryRegion (
|
|
|
|
IN EFI_PHYSICAL_ADDRESS MemBase,
|
|
|
|
IN UINT64 MemLength,
|
|
|
|
IN EFI_MEMORY_TYPE Type,
|
|
|
|
IN UINT64 Attributes
|
|
|
|
)
|
|
|
|
{
|
|
|
|
UINTN AlignedMemBase;
|
|
|
|
|
|
|
|
//
|
2024-05-14 03:46:15 +02:00
|
|
|
// Add EfiRuntimeServicesData for memory regions that is already allocated, needs testing, or needs ECC initialization
|
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 ((Attributes & (EFI_ALLOCATED | EFI_NEEDS_TESTING | EFI_NEEDS_ECC_INITIALIZATION)) != 0) {
|
2024-05-14 03:46:15 +02:00
|
|
|
Type = EfiRuntimeServicesData;
|
|
|
|
} else {
|
|
|
|
Type = EfiConventionalMemory;
|
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
|
|
|
}
|
|
|
|
|
|
|
|
//
|
|
|
|
// Align range on an EFI_PAGE_SIZE boundary
|
|
|
|
//
|
|
|
|
AlignedMemBase = (UINTN)(MemBase + EFI_PAGE_MASK) & ~EFI_PAGE_MASK;
|
|
|
|
MemLength -= AlignedMemBase - MemBase;
|
2024-05-14 03:46:15 +02:00
|
|
|
if (Type == EfiConventionalMemory) {
|
|
|
|
MmInternalFreePagesEx (AlignedMemBase, TRUNCATE_TO_PAGES ((UINTN)MemLength), TRUE);
|
|
|
|
} else {
|
|
|
|
ConvertMmMemoryMapEntry (EfiRuntimeServicesData, AlignedMemBase, TRUNCATE_TO_PAGES ((UINTN)MemLength), TRUE);
|
|
|
|
}
|
|
|
|
|
|
|
|
CoreFreeMemoryMapStack ();
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
This function returns a copy of the current memory map. The map is an array of
|
|
|
|
memory descriptors, each of which describes a contiguous block of memory.
|
|
|
|
|
|
|
|
@param[in, out] MemoryMapSize A pointer to the size, in bytes, of the
|
|
|
|
MemoryMap buffer. On input, this is the size of
|
|
|
|
the buffer allocated by the caller. On output,
|
|
|
|
it is the size of the buffer returned by the
|
|
|
|
firmware if the buffer was large enough, or the
|
|
|
|
size of the buffer needed to contain the map if
|
|
|
|
the buffer was too small.
|
|
|
|
@param[in, out] MemoryMap A pointer to the buffer in which firmware places
|
|
|
|
the current memory map.
|
|
|
|
@param[out] MapKey A pointer to the location in which firmware
|
|
|
|
returns the key for the current memory map.
|
|
|
|
@param[out] DescriptorSize A pointer to the location in which firmware
|
|
|
|
returns the size, in bytes, of an individual
|
|
|
|
EFI_MEMORY_DESCRIPTOR.
|
|
|
|
@param[out] DescriptorVersion A pointer to the location in which firmware
|
|
|
|
returns the version number associated with the
|
|
|
|
EFI_MEMORY_DESCRIPTOR.
|
|
|
|
|
|
|
|
@retval EFI_SUCCESS The memory map was returned in the MemoryMap
|
|
|
|
buffer.
|
|
|
|
@retval EFI_BUFFER_TOO_SMALL The MemoryMap buffer was too small. The current
|
|
|
|
buffer size needed to hold the memory map is
|
|
|
|
returned in MemoryMapSize.
|
|
|
|
@retval EFI_INVALID_PARAMETER One of the parameters has an invalid value.
|
|
|
|
|
|
|
|
**/
|
|
|
|
EFI_STATUS
|
|
|
|
EFIAPI
|
|
|
|
MmCoreGetMemoryMap (
|
|
|
|
IN OUT UINTN *MemoryMapSize,
|
|
|
|
IN OUT EFI_MEMORY_DESCRIPTOR *MemoryMap,
|
|
|
|
OUT UINTN *MapKey,
|
|
|
|
OUT UINTN *DescriptorSize,
|
|
|
|
OUT UINT32 *DescriptorVersion
|
|
|
|
)
|
|
|
|
{
|
|
|
|
UINTN Count;
|
|
|
|
LIST_ENTRY *Link;
|
|
|
|
MEMORY_MAP *Entry;
|
|
|
|
UINTN Size;
|
|
|
|
UINTN BufferSize;
|
|
|
|
|
|
|
|
Size = sizeof (EFI_MEMORY_DESCRIPTOR);
|
|
|
|
|
|
|
|
//
|
|
|
|
// Make sure Size != sizeof(EFI_MEMORY_DESCRIPTOR). This will
|
|
|
|
// prevent people from having pointer math bugs in their code.
|
|
|
|
// now you have to use *DescriptorSize to make things work.
|
|
|
|
//
|
|
|
|
Size += sizeof (UINT64) - (Size % sizeof (UINT64));
|
|
|
|
|
|
|
|
if (DescriptorSize != NULL) {
|
|
|
|
*DescriptorSize = Size;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (DescriptorVersion != NULL) {
|
|
|
|
*DescriptorVersion = EFI_MEMORY_DESCRIPTOR_VERSION;
|
|
|
|
}
|
|
|
|
|
|
|
|
Count = GetMmMemoryMapEntryCount ();
|
|
|
|
BufferSize = Size * Count;
|
|
|
|
if (*MemoryMapSize < BufferSize) {
|
|
|
|
*MemoryMapSize = BufferSize;
|
|
|
|
return EFI_BUFFER_TOO_SMALL;
|
|
|
|
}
|
|
|
|
|
|
|
|
*MemoryMapSize = BufferSize;
|
|
|
|
if (MemoryMap == NULL) {
|
|
|
|
return EFI_INVALID_PARAMETER;
|
|
|
|
}
|
|
|
|
|
|
|
|
ZeroMem (MemoryMap, BufferSize);
|
|
|
|
Link = gMemoryMap.ForwardLink;
|
|
|
|
while (Link != &gMemoryMap) {
|
|
|
|
Entry = CR (Link, MEMORY_MAP, Link, MEMORY_MAP_SIGNATURE);
|
|
|
|
Link = Link->ForwardLink;
|
|
|
|
|
|
|
|
MemoryMap->Type = Entry->Type;
|
|
|
|
MemoryMap->PhysicalStart = Entry->Start;
|
|
|
|
MemoryMap->NumberOfPages = RShiftU64 (Entry->End - Entry->Start + 1, EFI_PAGE_SHIFT);
|
|
|
|
|
|
|
|
MemoryMap = NEXT_MEMORY_DESCRIPTOR (MemoryMap, Size);
|
|
|
|
}
|
|
|
|
|
|
|
|
return 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
|
|
|
}
|