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

[Laszlo Ersek <lersek@redhat.com>]

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?

- 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