public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
From: Laszlo Ersek <lersek@redhat.com>
To: Brijesh Singh <brijesh.singh@amd.com>, edk2-devel@lists.01.org
Cc: Tom Lendacky <Thomas.Lendacky@amd.com>,
	Jordan Justen <jordan.l.justen@intel.com>,
	Ard Biesheuvel <ard.biesheuvel@linaro.org>,
	Michael Kinney <michael.d.kinney@intel.com>,
	Paolo Bonzini <pbonzini@redhat.com>
Subject: Re: [PATCH 2/2] OvmfPkg/QemuFlashFvbServicesRuntimeDxe: Clear C-bit when SEV is active
Date: Thu, 22 Feb 2018 13:08:04 +0100	[thread overview]
Message-ID: <6a0cd77f-13d8-b8dd-8ad2-931347e72a7c@redhat.com> (raw)
In-Reply-To: <20180221165212.6643-3-brijesh.singh@amd.com>

On 02/21/18 17:52, Brijesh Singh wrote:
> Commit:24e4ad7 (OvmfPkg: Add AmdSevDxe driver) added a driver which runs
> early in PEI phase and clears the C-bit from all MMIO regions (including

s/PEI/DXE/


> Qemu Flash). When SMM is enabled, we build two sets of page tables; first
> page table is used when executing code in non SMM mode (SMM-less-pgtable)
> and second page table is used when we are executing code in SMM mode
> (SMM-pgtable).
> 
> During boot time, AmdSevDxe driver clears the C-bit from the
> SMM-less-pgtable. But when SMM is enabled, Qemu Flash services are used
> from SMM mode.
> 
> In this patch we explicitly clear the C-bit from Qemu flash MMIO range
> before we probe the flash. When OVMF is built with SMM_REQUIRE then
> call to initialize the flash services happen after the SMM-pgtable is
> created and processor is serving the first SMI. At this time we will
> have access to the SMM-pgtable.

The problem statement is good (including the comment in the code).

However, I would prefer if we could reflect the full AmdSevDxe logic to
the SMM page tables. In other words, when -- or shortly after -- the SMM
page tables are built, we should clear the C-bit in all those PTEs that
cover known MMIO and as-yet NonExistent memory ranges. We already have a
bunch of "mAddressEncMask" usage in PiSmmCpuDxeSmm.

Can we investigate this a bit? If it turns out to be impossible, I guess
I might be OK with this patch.

I have more comments:


> 
> 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/QemuFlashFvbServicesRuntimeDxe/FvbServicesSmm.inf  |  1 +
>  OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FwBlockService.h    |  5 +++
>  OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FwBlockService.c    |  5 +++
>  OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FwBlockServiceDxe.c | 10 ++++++
>  OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FwBlockServiceSmm.c | 35 ++++++++++++++++++++
>  5 files changed, 56 insertions(+)
> 
> diff --git a/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FvbServicesSmm.inf b/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FvbServicesSmm.inf
> index ba2d3679a46d..d365e27cbe59 100644
> --- a/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FvbServicesSmm.inf
> +++ b/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FvbServicesSmm.inf
> @@ -53,6 +53,7 @@ [LibraryClasses]
>    DevicePathLib
>    DxeServicesTableLib
>    MemoryAllocationLib
> +  MemEncryptSevLib
>    PcdLib
>    SmmServicesTableLib
>    UefiBootServicesTableLib
> diff --git a/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FwBlockService.h b/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FwBlockService.h
> index 1f9287b08769..704ed477ba14 100644
> --- a/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FwBlockService.h
> +++ b/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FwBlockService.h
> @@ -189,4 +189,9 @@ VOID
>  InstallVirtualAddressChangeHandler (
>    VOID
>    );
> +
> +VOID
> +FvbBeforeFlashProbe (
> +  VOID
> +  );
>  #endif

Please drop the "Fvb" prefix; this function is not an FVB protocol member.


> diff --git a/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FwBlockService.c b/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FwBlockService.c
> index 558b395dff4a..b7b9bf1fb8d9 100644
> --- a/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FwBlockService.c
> +++ b/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FwBlockService.c
> @@ -967,6 +967,11 @@ FvbInitialize (
>    UINTN                               NumOfBlocks;
>    RETURN_STATUS                       PcdStatus;
>  
> +  //
> +  // execute platform specific hooks before probing the flash
> +  //
> +  FvbBeforeFlashProbe ();
> +
>    if (EFI_ERROR (QemuFlashInitialize ())) {
>      //
>      // Return an error so image will be unloaded
> diff --git a/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FwBlockServiceDxe.c b/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FwBlockServiceDxe.c
> index 63b308658e36..7d274c08ad12 100644
> --- a/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FwBlockServiceDxe.c
> +++ b/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FwBlockServiceDxe.c
> @@ -155,3 +155,13 @@ InstallVirtualAddressChangeHandler (
>                    );
>    ASSERT_EFI_ERROR (Status);
>  }
> +
> +VOID
> +FvbBeforeFlashProbe (
> +  VOID
> +  )
> +{
> +  //
> +  // Do nothing
> +  //
> +}
> diff --git a/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FwBlockServiceSmm.c b/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FwBlockServiceSmm.c
> index e0617f2503a2..d97b13f47bf7 100644
> --- a/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FwBlockServiceSmm.c
> +++ b/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FwBlockServiceSmm.c
> @@ -17,6 +17,7 @@
>  #include <Library/DebugLib.h>
>  #include <Library/PcdLib.h>
>  #include <Library/SmmServicesTableLib.h>
> +#include <Library/MemEncryptSevLib.h>
>  #include <Protocol/DevicePath.h>
>  #include <Protocol/SmmFirmwareVolumeBlock.h>
>  
> @@ -67,3 +68,37 @@ InstallVirtualAddressChangeHandler (
>    // Nothing.
>    //
>  }
> +
> +VOID
> +FvbBeforeFlashProbe (
> +  VOID
> +  )
> +{
> +
> +  ASSERT (FeaturePcdGet (PcdSmmSmramRequire));
> +
> +  //
> +  // When SEV is enabled, AmdSevDxe runs early in PEI phase and clears the C-bit

s/PEI/DXE/


> +  // from the MMIO space (including flash ranges) but the driver runs in non SMM
> +  // context hence it cleared the flash ranges from non SMM page table.
> +  // When SMM is enabled, the flash services are accessed from the SMM mode
> +  // hence we explicitly clear the C-bit on flash ranges from SMM page table.
> +  //
> +  if (MemEncryptSevIsEnabled ()) {
> +    EFI_STATUS              Status;
> +    EFI_PHYSICAL_ADDRESS    BaseAddress;
> +    UINTN                   FdBlockSize, FdBlockCount;
> +
> +    BaseAddress = (EFI_PHYSICAL_ADDRESS) PcdGet32 (PcdOvmfFdBaseAddress);
> +    FdBlockSize = PcdGet32 (PcdOvmfFirmwareBlockSize);
> +    FdBlockCount = PcdGet32 (PcdOvmfFirmwareFdSize) / FdBlockSize;
> +
> +    Status = MemEncryptSevClearPageEncMask (
> +               0,
> +               BaseAddress,
> +               EFI_SIZE_TO_PAGES (FdBlockSize * FdBlockCount),
> +               FALSE
> +              );
> +    ASSERT_EFI_ERROR (Status);
> +  }
> +}
> 

I think it would be better to hook this logic into
QemuFlashInitialize(). That function already computes mFlashBase,
mFdBlockSize and mFdBlockCount. Right before the call to
QemuFlashDetected(), we could call BeforeFlashProbe(). The latter could
take the base address, the block size and count as parameters, or just
use the global variables.


But, again, my preference would be to mirror the AmdSevDxe logic into
(or right after) the SMM page table setup. Perhaps that can be done in
SmmCpuFeaturesInitializeProcessor(), when IsMonarch is TRUE -- this
function is called from SmmInitHandler(), and at that point, the SMM
page tables are already in use. (See above the SmmInitHandler() call
site in "UefiCpuPkg/PiSmmCpuDxeSmm/X64/SmmInit.nasm".)

Thanks,
Laszlo


  reply	other threads:[~2018-02-22 12:02 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-02-21 16:52 [PATCH 0/2] Add SMM support when SEV is active Brijesh Singh
2018-02-21 16:52 ` [PATCH 1/2] OvmfPkg/AmdSevDxe: Clear the C-bit from SMM Saved State Brijesh Singh
2018-02-22 11:20   ` Laszlo Ersek
2018-02-22 11:21     ` Laszlo Ersek
2018-02-27 12:17     ` Brijesh Singh
2018-02-21 16:52 ` [PATCH 2/2] OvmfPkg/QemuFlashFvbServicesRuntimeDxe: Clear C-bit when SEV is active Brijesh Singh
2018-02-22 12:08   ` Laszlo Ersek [this message]
2018-02-27 12:23     ` Brijesh Singh
2018-02-27 17:17       ` Laszlo Ersek
2018-02-27 20:37         ` Brijesh Singh
2018-02-28 15:21           ` Brijesh Singh

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-list from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=6a0cd77f-13d8-b8dd-8ad2-931347e72a7c@redhat.com \
    --to=devel@edk2.groups.io \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox