public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
From: Jordan Justen <jordan.l.justen@intel.com>
To: Laszlo Ersek <lersek@redhat.com>,
	edk2-devel-01 <edk2-devel@lists.01.org>
Cc: Brijesh Singh <brijesh.singh@amd.com>,
	Tom Lendacky <thomas.lendacky@amd.com>
Subject: Re: [PATCH 1/1] OvmfPkg/QemuFwCfgDxeLib: SEV: zero FW_CFG_DMA_ACCESS before decrypting it
Date: Tue, 29 Aug 2017 01:11:03 -0400	[thread overview]
Message-ID: <150398346137.25288.10980860099496106545@jljusten-skl> (raw)
In-Reply-To: <20170828123928.14627-2-lersek@redhat.com>

Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>

On 2017-08-28 08:39:28, Laszlo Ersek wrote:
> There's a small window between
> 
> - AllocFwCfgDmaAccessBuffer() mapping the new FW_CFG_DMA_ACCESS object for
>   common buffer operation (i.e., decrypting it), and
> 
> - InternalQemuFwCfgDmaBytes() setting the fields of the object.
> 
> In this window, earlier garbage in the object is "leaked" to the
> hypervisor. So zero the object before we decrypt it.
> 
> (This commit message references AMD SEV directly, because QemuFwCfgDxeLib
> is not *generally* enabled for IOMMU operation just yet, unlike our goal
> for the virtio infrastructure. Instead, QemuFwCfgDxeLib uses
> MemEncryptSevLib explicitly to detect SEV, and then relies on IOMMU
> protocol behavior that is specific to SEV. At this point, this is by
> design.)
> 
> Cc: Brijesh Singh <brijesh.singh@amd.com>
> Cc: Jordan Justen <jordan.l.justen@intel.com>
> Cc: Tom Lendacky <thomas.lendacky@amd.com>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Laszlo Ersek <lersek@redhat.com>
> ---
>  OvmfPkg/Library/QemuFwCfgLib/QemuFwCfgDxe.c | 7 +++++++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/OvmfPkg/Library/QemuFwCfgLib/QemuFwCfgDxe.c b/OvmfPkg/Library/QemuFwCfgLib/QemuFwCfgDxe.c
> index 8b98208591e6..22077851a40c 100644
> --- a/OvmfPkg/Library/QemuFwCfgLib/QemuFwCfgDxe.c
> +++ b/OvmfPkg/Library/QemuFwCfgLib/QemuFwCfgDxe.c
> @@ -1,29 +1,30 @@
>  /** @file
>  
>    Stateful and implicitly initialized fw_cfg library implementation.
>  
>    Copyright (C) 2013, Red Hat, Inc.
>    Copyright (c) 2011 - 2013, Intel Corporation. All rights reserved.<BR>
>    Copyright (c) 2017, Advanced Micro Devices. All rights reserved.<BR>
>  
>    This program and the accompanying materials are licensed and made available
>    under the terms and conditions of the BSD License which accompanies this
>    distribution.  The full text of the license may be found at
>    http://opensource.org/licenses/bsd-license.php
>  
>    THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS, WITHOUT
>    WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
>  **/
>  
>  #include <Uefi.h>
>  
>  #include <Protocol/IoMmu.h>
>  
>  #include <Library/BaseLib.h>
> +#include <Library/BaseMemoryLib.h>
>  #include <Library/IoLib.h>
>  #include <Library/DebugLib.h>
>  #include <Library/QemuFwCfgLib.h>
>  #include <Library/UefiBootServicesTableLib.h>
>  #include <Library/MemEncryptSevLib.h>
>  
>  #include "QemuFwCfgLibInternal.h"
> @@ -155,75 +156,81 @@ VOID
>  AllocFwCfgDmaAccessBuffer (
>    OUT   VOID     **Access,
>    OUT   VOID     **MapInfo
>    )
>  {
>    UINTN                 Size;
>    UINTN                 NumPages;
>    EFI_STATUS            Status;
>    VOID                  *HostAddress;
>    EFI_PHYSICAL_ADDRESS  DmaAddress;
>    VOID                  *Mapping;
>  
>    Size = sizeof (FW_CFG_DMA_ACCESS);
>    NumPages = EFI_SIZE_TO_PAGES (Size);
>  
>    //
>    // As per UEFI spec, in order to map a host address with
>    // BusMasterCommomBuffer64, the buffer must be allocated using the IOMMU
>    // AllocateBuffer()
>    //
>    Status = mIoMmuProtocol->AllocateBuffer (
>                               mIoMmuProtocol,
>                               AllocateAnyPages,
>                               EfiBootServicesData,
>                               NumPages,
>                               &HostAddress,
>                               EDKII_IOMMU_ATTRIBUTE_DUAL_ADDRESS_CYCLE
>                               );
>    if (EFI_ERROR (Status)) {
>      DEBUG ((DEBUG_ERROR,
>        "%a:%a failed to allocate FW_CFG_DMA_ACCESS\n", gEfiCallerBaseName,
>        __FUNCTION__));
>      ASSERT (FALSE);
>      CpuDeadLoop ();
>    }
>  
> +  //
> +  // Avoid exposing stale data even temporarily: zero the area before mapping
> +  // it.
> +  //
> +  ZeroMem (HostAddress, Size);
> +
>    //
>    // Map the host buffer with BusMasterCommonBuffer64
>    //
>    Status = mIoMmuProtocol->Map (
>                               mIoMmuProtocol,
>                               EdkiiIoMmuOperationBusMasterCommonBuffer64,
>                               HostAddress,
>                               &Size,
>                               &DmaAddress,
>                               &Mapping
>                               );
>    if (EFI_ERROR (Status)) {
>      mIoMmuProtocol->FreeBuffer (mIoMmuProtocol, NumPages, HostAddress);
>      DEBUG ((DEBUG_ERROR,
>        "%a:%a failed to Map() FW_CFG_DMA_ACCESS\n", gEfiCallerBaseName,
>        __FUNCTION__));
>      ASSERT (FALSE);
>      CpuDeadLoop ();
>    }
>  
>    if (Size < sizeof (FW_CFG_DMA_ACCESS)) {
>      mIoMmuProtocol->Unmap (mIoMmuProtocol, Mapping);
>      mIoMmuProtocol->FreeBuffer (mIoMmuProtocol, NumPages, HostAddress);
>      DEBUG ((DEBUG_ERROR,
>        "%a:%a failed to Map() - requested 0x%Lx got 0x%Lx\n", gEfiCallerBaseName,
>        __FUNCTION__, (UINT64)sizeof (FW_CFG_DMA_ACCESS), (UINT64)Size));
>      ASSERT (FALSE);
>      CpuDeadLoop ();
>    }
>  
>    *Access = HostAddress;
>    *MapInfo = Mapping;
>  }
>  
>  /**
>    Function is to used for freeing the Access buffer allocated using
>    AllocFwCfgDmaAccessBuffer()
>  
>  **/
> -- 
> 2.14.1.3.gb7cf6e02401b
> 


  reply	other threads:[~2017-08-29  5:08 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-08-28 12:39 [PATCH 0/1] OvmfPkg/QemuFwCfgDxeLib: SEV: zero FW_CFG_DMA_ACCESS before decrypting it Laszlo Ersek
2017-08-28 12:39 ` [PATCH 1/1] " Laszlo Ersek
2017-08-29  5:11   ` Jordan Justen [this message]
2017-08-29 14:02   ` Brijesh Singh
2017-08-29 20:47     ` Laszlo Ersek

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=150398346137.25288.10980860099496106545@jljusten-skl \
    --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