Re: [edk2-devel] [PATCH v3 08/13] OvmfPkg/PlatformInitLib: Create gEfiSmmSmramMemoryGuid

["Wu, Jiaxin" <jiaxin.wu@intel.com>]

> 
> 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/7686176
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [rebecca@openfw.io]
-=-=-=-=-=-=-=-=-=-=-=-