Re: [PATCH 1/2] OvmfPkg/AmdSevDxe: Clear the C-bit from SMM Saved State

[Laszlo Ersek <lersek@redhat.com>]

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.justen@intel.com>
>> Cc: Laszlo Ersek <lersek@redhat.com>
>> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
>> Contributed-under: TianoCore Contribution Agreement 1.1
>> Signed-off-by: Brijesh Singh <brijesh.singh@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
>