From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id BD334208F7A59 for ; Thu, 3 Aug 2017 07:38:09 -0700 (PDT) Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id CF3E4356EA; Thu, 3 Aug 2017 14:40:20 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com CF3E4356EA Authentication-Results: ext-mx06.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx06.extmail.prod.ext.phx2.redhat.com; spf=fail smtp.mailfrom=lersek@redhat.com Received: from lacos-laptop-7.usersys.redhat.com (ovpn-116-72.phx2.redhat.com [10.3.116.72]) by smtp.corp.redhat.com (Postfix) with ESMTP id 4D8927E0BA; Thu, 3 Aug 2017 14:40:19 +0000 (UTC) To: Brijesh Singh Cc: edk2-devel-01 , Ard Biesheuvel , Jordan Justen , Tom Lendacky , Andrew Fish References: <20170802212453.19221-1-lersek@redhat.com> <20170802212453.19221-11-lersek@redhat.com> <560549ae-700a-2a1c-db97-0851d3a12fe1@amd.com> <4eda3a9b-6be8-ef61-117a-ebff5e988629@redhat.com> <1a75582e-a3ba-d20c-75b8-c558cd373787@amd.com> From: Laszlo Ersek Message-ID: <294adc6a-1eb7-3ce2-6ae5-15392826fe54@redhat.com> Date: Thu, 3 Aug 2017 16:40:18 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 2.79 on 10.5.11.14 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.30]); Thu, 03 Aug 2017 14:40:21 +0000 (UTC) Subject: Re: [PATCH 10/12] OvmfPkg/IoMmuDxe: implement in-place decryption/encryption for Map/Unmap X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Aug 2017 14:38:10 -0000 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit On 08/03/17 16:35, Brijesh Singh wrote: > Laszlo, > > One minor issue, I got compilation error with GCC48. > > /home/brijesh/codomania/edk2-new/edk2/OvmfPkg/IoMmuDxe/AmdSevIoMmu.c: In > function ‘IoMmuUnmap’: > /home/brijesh/codomania/edk2-new/edk2/OvmfPkg/IoMmuDxe/AmdSevIoMmu.c:408:25: > error: ‘CommonBufferHeader’ may be used uninitialized in this function > [-Werror=maybe-uninitialized] > CommonBufferHeader->StashBuffer, > > Looks like we need to initialize CommonBufferHeader = NULL to keep GCC48 > happy. Interesting, I use GCC48 all the time (as part of RHEL7 on my laptop), and I didn't get this warning. I'll suppress it. Thank you for the report! Laszlo > > thanks > > On 08/02/2017 08:09 PM, Brijesh Singh wrote: >> >> >> On 8/2/17 7:13 PM, Laszlo Ersek wrote: >>> (CC Andrew) >>> >>> On 08/03/17 01:01, Brijesh Singh wrote: >>>> >>>> On 8/2/17 4:24 PM, Laszlo Ersek wrote: >>>> >>>> [Snip] >>>>> At the moment, we have the foll+ // The buffer at >>>>> MapInfo->CryptedAddress comes from AllocateBuffer(). >>>>> // >>>>> MapInfo->PlainTextAddress = MapInfo->CryptedAddress; >>>>> - >>>>> // >>>>> - // Therefore no mapping is necessary. >>>>> + // Stash the crypted data. >>>>> // >>>>> - *DeviceAddress = MapInfo->PlainTextAddress; >>>>> - *Mapping = NO_MAPPING; >>>>> - FreePool (MapInfo); >>>>> - return EFI_SUCCESS; >>>>> + CommonBufferHeader = (COMMON_BUFFER_HEADER *)( >>>>> + (UINTN)MapInfo->CryptedAddress - >>>>> EFI_PAGE_SIZE >>>>> + ); >>>> One question, per spec, is it legal for client to call Map() at some >>>> offset within allocated buffer ? >>>> >>>> e.g something like this: >>>> >>>> * AllocateBuffer (, 1, &Buffer); >>>> * MapBuffer = Buffer + 10; >>>> * Map (, BusMasterCommonBuffer, MappedBuffer, 10, ..) // Bascially Map >>>> 10 bytes from offset 10 >>> The input/output parameter names seem to counter-indicate such use. >>> Namely, AllocateBuffer() outputs a "HostAddress" param, and Map() takes >>> a "HostAddress" param. Plus we have sentences like this: >>> >>> Under PciIo.Map(): >>> >>>> ... only memory allocated via the AllocateBuffer() interface can be >>>> mapped for this type of operation ... >>> Under PciIo.AllocateBuffer(): >>> >>>> The AllocateBuffer() function allocates pages that are suitable for an >>>> EfiPciOperationBusMasterCommonBuffer or >>>> EfiPciOperationBusMasterCommonBuffer64 mapping. This means that the >>>> buffer allocated by this function must support simultaneous access by >>>> both the processor and a PCI Bus Master. The device address that the >>>> PCI Bus Master uses to access *the* buffer can be retrieved with a >>>> call to Map(). >>> This second passage says *the* buffer. (Emphasis mine above.) >>> >>>> If this is legal then we may need to build MapInfo during >>>> AllocateBuffer() to locate the "StashBuffer". >>> Right, in that case we'd have to build a list of allocated ranges (an >>> interval tree of sorts) in AllocateBuffer, and convert any >>> CommonBuffer[64] Map() call to its containing allocation with a search. >>> >>> It would be worse than that, actually... The pattern you have raised >>> could be taken one step further: do one AllocateBuffer(), and several >>> CommonBuffer[64] Map()s into it :) What should happen if those maps are >>> distinct? What should happen if they overlap? :) I can't even imagine >>> what this would mean for SEV. >>> >>> ... There are guide-like sections in the generic description of >>> EFI_PCI_IO_PROTOCOL; Andrew quoted them earlier: >>> >>> >>> http://mid.mail-archive.com/A29CDE8F-C82A-4C92-ABF8-008A9BF8F230@apple.com >>> >>> >>>> DMA Bus Master Common Buffer Operation >>>> ====================================== >>>> * Call AllocateBuffer() to allocate a common buffer. >>>> * Call Map() for EfiPciIoOperationBusMasterCommonBuffer. >>>> * Program the DMA Bus Master with the DeviceAddress returned by Map(). >>>> * The common buffer can now be accessed equally by the processor and >>>> the DMA bus master. >>>> * Call Unmap(). >>>> * Call FreeBuffer(). >>> Look at page 854 (printed page number: 784) in UEFI 2.7. >>> >>> Thus, I don't think the usage you raise is permitted. >> >> Sounds good. I did a quick test on SEV hardware, everything seems to be >> working well. I have started my stresstest and report the result >> tomorrow. >> >> -Brijesh >>