>
> SmramInternal.c handles that. It creates two regions, one is a page at
> the start of SMRAM where S3 state is stored (and marked as allocated),
> one is all the rest.
>
Yes, the same logic is moved to the OvmfPkg/Library/PlatformInitLib/MemDetect.c:
//
// Create first SMRAM descriptor, which contains data structures used in S3
resume.
// One page is enough for the data structure
//
SmramHobDescriptorBlock->Descriptor[0].PhysicalStart =
PlatformInfoHob->LowMemory - TsegSize;
SmramHobDescriptorBlock->Descriptor[0].CpuStart =
PlatformInfoHob->LowMemory - TsegSize;
SmramHobDescriptorBlock->Descriptor[0].PhysicalSize = EFI_PAGE_SIZE;
SmramHobDescriptorBlock->Descriptor[0].RegionState = EFI_SMRAM_CLOSED |
EFI_CACHEABLE | EFI_ALLOCATED;
//
// Create second SMRAM descriptor, which is free and will be used by SMM
foundation.
//
SmramHobDescriptorBlock->Descriptor[1].PhysicalStart =
SmramHobDescriptorBlock->Descriptor[0].PhysicalStart + EFI_PAGE_SIZE;
SmramHobDescriptorBlock->Descriptor[1].CpuStart =
SmramHobDescriptorBlock->Descriptor[0].CpuStart + EFI_PAGE_SIZE;
SmramHobDescriptorBlock->Descriptor[1].PhysicalSize = TsegSize -
EFI_PAGE_SIZE;
SmramHobDescriptorBlock->Descriptor[1].RegionState = EFI_SMRAM_CLOSED |
EFI_CACHEABLE;
> So, if you need some smram to initialize SMM in PEI I'd suggest to
> either add a third region, or make the first region larger.
>
> It's not clear to me why you put the logic upside down and introduce
> that HOB in the first place.
>
Let me explain more why need this change:
1. The EFI_SMM_SMRAM_MEMORY_GUID HOB, as defined in the PI specification, is
used to describe the SMRAM memory regions supported by the platform. This HOB
should be produced during the memory detection phase to align with the PI spec.
2. In addition to the memory reserved for ACPI S3 resume, an increasing number
of features require reserving SMRAM for specific purposes, such as
SmmRelocation. Other advanced features in Intel platforms also necessitate
this. The implementation of these features varies and is entirely dependent on
the platform. This is why an increasing number of platforms are adopting the
EFI_SMM_SMRAM_MEMORY_GUID HOB for SMRAM description.
3. It is crucial that the SMRAM information remains consistent when retrieved
from the platform, whether through the SMM ACCESS PPI/Protocol or the
EFI_SMM_SMRAM_MEMORY_GUID HOB. Inconsistencies can lead to unexpected issues,
most commonly memory region conflicts.
4. The SMM ACCESS PPI/Protocol can be naturally implemented for general use.
The common approach is to utilize the EFI_SMM_SMRAM_MEMORY_GUID HOB. For
reference, see the existing implementation in the EDK2 repository at
edk2/UefiPayloadPkg/SmmAccessDxe/SmmAccessDxe.inf and
edk2-platforms/Silicon/Intel/IntelSiliconPkg/Feature/SmmAccess/Library/PeiSmmAccessLib/PeiSmmAccessLib.inf.
For the reasons mentioned, we are moving the SMRAM memory regions to HOBs and
allowing SMM access to consume these HOBs.
I will add the above info into commit message.
>
> Storing anything SMM related outside SMRAM makes me nervous.
> I'd strongly suggest to avoid that.
>
> It might be that in this specific case it is not a problem. But it
> needs very careful review of the implications (which I have not done)
> and you have to hope you don't miss a possible attack vector, such as
> someone modifying the HOB and the firmware then storing SMM data + code
> outside SMRAM.
>
Understand, but here is the case we can record the info in non-smram since PI
spec exposes that, there is no difference the info retrieved from PPI/ non-smm
Protocol or the non-smram.
Thanks,
Jiaxin
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#118253): https://edk2.groups.io/g/devel/message/118253
Mute This Topic: https://groups.io/mt/105593577/21656
Group Owner: [email protected]
Unsubscribe: https://edk2.groups.io/g/devel/unsub [[email protected]]
-=-=-=-=-=-=-=-=-=-=-=-
