On 02/22/18 12:20, Laszlo Ersek wrote:
> Hi Brijesh!
>
> (adding Paolo and Mike; more comments below)
>
> On 02/21/18 17:52, Brijesh Singh wrote:
>> When OVMF is built with SMM, SMMSaved State area (SMM_DEFAULT_SMBASE +
>> SMRAM_SAVE_STATE_MAP_OFFSET) contains data which need to be accessed by
>> both guest and hypervisor. Since the data need to be accessed by both
>> hence we must map the SMMSaved State area as unencrypted (i.e C-bit
>> cleared).
>>
>> Cc: Jordan Justen <jordan.l.jus...@intel.com>
>> Cc: Laszlo Ersek <ler...@redhat.com>
>> Cc: Ard Biesheuvel <ard.biesheu...@linaro.org>
>> Contributed-under: TianoCore Contribution Agreement 1.1
>> Signed-off-by: Brijesh Singh <brijesh.si...@amd.com>
>> ---
>> OvmfPkg/AmdSevDxe/AmdSevDxe.inf | 4 ++++
>> OvmfPkg/AmdSevDxe/AmdSevDxe.c | 19 +++++++++++++++++++
>> 2 files changed, 23 insertions(+)
>>
>> diff --git a/OvmfPkg/AmdSevDxe/AmdSevDxe.inf
>> b/OvmfPkg/AmdSevDxe/AmdSevDxe.inf
>> index 41635a57a454..162ed98a2fbe 100644
>> --- a/OvmfPkg/AmdSevDxe/AmdSevDxe.inf
>> +++ b/OvmfPkg/AmdSevDxe/AmdSevDxe.inf
>> @@ -29,6 +29,7 @@ [Packages]
>> MdePkg/MdePkg.dec
>> MdeModulePkg/MdeModulePkg.dec
>> OvmfPkg/OvmfPkg.dec
>> + UefiCpuPkg/UefiCpuPkg.dec
>>
>> [LibraryClasses]
>> BaseLib
>> @@ -41,3 +42,6 @@ [LibraryClasses]
>>
>> [Depex]
>> TRUE
>> +
>> +[FeaturePcd]
>> + gUefiOvmfPkgTokenSpaceGuid.PcdSmmSmramRequire
>> diff --git a/OvmfPkg/AmdSevDxe/AmdSevDxe.c b/OvmfPkg/AmdSevDxe/AmdSevDxe.c
>> index e472096320ea..5ec727456526 100644
>> --- a/OvmfPkg/AmdSevDxe/AmdSevDxe.c
>> +++ b/OvmfPkg/AmdSevDxe/AmdSevDxe.c
>> @@ -25,6 +25,8 @@
>> #include <Library/UefiBootServicesTableLib.h>
>> #include <Library/DxeServicesTableLib.h>
>> #include <Library/MemEncryptSevLib.h>
>> +#include <Register/SmramSaveStateMap.h>
>> +#include <Register/QemuSmramSaveStateMap.h>
>>
>> EFI_STATUS
>> EFIAPI
>> @@ -71,5 +73,22 @@ AmdSevDxeEntryPoint (
>> FreePool (AllDescMap);
>> }
>>
>> + //
>> + // When SMM is enabled, clear the C-bit from SMM Saved State Area
>> + //
>> + if (FeaturePcdGet (PcdSmmSmramRequire)) {
>> + EFI_PHYSICAL_ADDRESS SmmSavedStateAreaAddress;
>> +
>> + SmmSavedStateAreaAddress = SMM_DEFAULT_SMBASE +
>> SMRAM_SAVE_STATE_MAP_OFFSET;
>> +
>> + Status = MemEncryptSevClearPageEncMask (
>> + 0,
>> + SmmSavedStateAreaAddress,
>> + EFI_SIZE_TO_PAGES (sizeof(QEMU_SMRAM_SAVE_STATE_MAP)),
>> + FALSE
>> + );
>> + ASSERT_EFI_ERROR (Status);
>> + }
>> +
>> return EFI_SUCCESS;
>> }
>>
>
> First, this SMBASE address is only correct before SMBASE relocation.
>
> - What guarantees that AmdSevDxe is dispatched, and the new code is
> executed, before PiSmmCpuDxeSmm performs the SMBASE relocation?
Apologies, I forgot (and missed) that AmdSevDxe is listed in APRIORI
DXE. So consider this part answered.
Thanks!
Laszlo
>
> - Where/when do we clear encryption for the state map that is used after
> SMBASE relocation? If we don't do that at all, then why do things
> work? (I see a whole lot of "mAddressEncMask" in PiSmmCpuDxeSmm; some
> help would be appreciated.)
>
> Second, after SMBASE relocation, when/where do we restore the C bit on
> the original (default) SMBASE? I think we should do that, otherwise
> we'll have an info leak there.
>
> Third, why is it OK to pass Flush=FALSE? The documentation says, "mostly
> TRUE except MMIO addresses". The default SMBASE points into memory, not
> MMIO; there could be normal data there. PiSmmCpuDxeSmm backs up the area
> before SMBASE relocation, and restores it after. See SmmRelocateBases()
> in "UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.c":
>
> //
> // Backup original contents at address 0x38000
> //
> CopyMem (BakBuf, U8Ptr, sizeof (BakBuf));
> CopyMem (&BakBuf2, CpuStatePtr, sizeof (BakBuf2));
>
> I wonder if we should introduce new SmmCpuFeaturesLib APIs, for managing
> memory encryption settings around SMBASE relocation.
> - PiSmmCpuDxeSemm could call these APIs in "strategic places".
> - The SmmCpuFeaturesLib instances in UefiCpuPkg and QuarkSocPkg would do
> nothing.
> - The instace under OvmfPkg would handle the C-bit, dependent on SEV
> presence.
>
> The lib class already has a function called
> SmmCpuFeaturesSmmRelocationComplete(); we might be able to use that (too).
>
> Thanks,
> Laszlo
>
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
