public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
From: Brijesh Singh <brijesh.singh@amd.com>
To: Laszlo Ersek <lersek@redhat.com>, edk2-devel@lists.01.org
Cc: brijesh.singh@amd.com, 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: Tue, 27 Feb 2018 06:23:11 -0600	[thread overview]
Message-ID: <8138d8c3-678f-fd42-c663-1ae5c2e539b9@amd.com> (raw)
In-Reply-To: <6a0cd77f-13d8-b8dd-8ad2-931347e72a7c@redhat.com>



On 2/22/18 6:08 AM, Laszlo Ersek wrote:
> 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 will investigate this a bit. The reason why I didn't replicated full
AmdSevDxe logic is because I thought in SMM world we don't need to do
all those MMIO accesses etc but if its not the case then I agree we
should implement the full logic here.


>
> 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.

Will do.

>
>
>> 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/

Will do.
>
>
>> +  // 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.
>

Let me see what I can do.

> 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".)

Ah, I didn't know this one. I got SMM working with very small patch set
hence never looked in UefiCpuPkg for complete understanding of various
SmmFeatureLib routines but now I am looking more into it and I think we
may able to use SmmCpuFeatureInitializeProcessor() routines.

> Thanks,
> Laszlo



  reply	other threads:[~2018-02-27 12:17 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
2018-02-27 12:23     ` Brijesh Singh [this message]
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=8138d8c3-678f-fd42-c663-1ae5c2e539b9@amd.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