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>
Cc: edk2-devel-01 <edk2-devel@lists.01.org>,
	Ard Biesheuvel <ard.biesheuvel@linaro.org>,
	Jordan Justen <jordan.l.justen@intel.com>,
	Tom Lendacky <thomas.lendacky@amd.com>,
	Andrew Fish <afish@apple.com>
Subject: Re: [PATCH 10/12] OvmfPkg/IoMmuDxe: implement in-place decryption/encryption for Map/Unmap
Date: Thu, 3 Aug 2017 16:40:18 +0200	[thread overview]
Message-ID: <294adc6a-1eb7-3ce2-6ae5-15392826fe54@redhat.com> (raw)
In-Reply-To: <ce614a16-117c-e904-ac5c-ed56bd729e06@amd.com>

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



  reply	other threads:[~2017-08-03 14:38 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-08-02 21:24 [PATCH 00/12] OvmfPkg/IoMmuDxe: cleanups and fixes Laszlo Ersek
2017-08-02 21:24 ` [PATCH 01/12] OvmfPkg/IoMmuDxe: rewrap source code to 79 characters Laszlo Ersek
2017-08-02 21:24 ` [PATCH 02/12] OvmfPkg/IoMmuDxe: rename DeviceAddress to PlainTextAddress in MAP_INFO Laszlo Ersek
2017-08-02 21:24 ` [PATCH 03/12] OvmfPkg/IoMmuDxe: rename HostAddress to CryptedAddress " Laszlo Ersek
2017-08-02 21:24 ` [PATCH 04/12] OvmfPkg/IoMmuDxe: convert UINTN arguments to UINT64 for the %Lx fmt spec Laszlo Ersek
2017-08-02 21:24 ` [PATCH 05/12] OvmfPkg/IoMmuDxe: don't initialize local variables Laszlo Ersek
2017-08-02 21:24 ` [PATCH 06/12] OvmfPkg/IoMmuDxe: propagate errors from AmdSevInstallIoMmuProtocol() Laszlo Ersek
2017-08-02 21:24 ` [PATCH 07/12] OvmfPkg/IoMmuDxe: clean up used library classes Laszlo Ersek
2017-08-02 21:24 ` [PATCH 08/12] OvmfPkg/IoMmuDxe: zero out pages before releasing them Laszlo Ersek
2017-08-02 21:24 ` [PATCH 09/12] OvmfPkg/IoMmuDxe: rework setup of "MapInfo->PlainTextAddress" in Map() Laszlo Ersek
2017-08-02 21:24 ` [PATCH 10/12] OvmfPkg/IoMmuDxe: implement in-place decryption/encryption for Map/Unmap Laszlo Ersek
2017-08-02 23:01   ` Brijesh Singh
2017-08-03  0:13     ` Laszlo Ersek
2017-08-03  1:09       ` Brijesh Singh
2017-08-03 14:35         ` Brijesh Singh
2017-08-03 14:40           ` Laszlo Ersek [this message]
2017-08-02 21:24 ` [PATCH 11/12] OvmfPkg/IoMmuDxe: abort harder on memory encryption mask failures Laszlo Ersek
2017-08-02 21:24 ` [PATCH 12/12] OvmfPkg/IoMmuDxe: Unmap(): recycle MAP_INFO after BusMasterCommonBuffer[64] Laszlo Ersek
2017-08-02 21:31 ` [PATCH 00/12] OvmfPkg/IoMmuDxe: cleanups and fixes Laszlo Ersek
2017-08-03 14:10 ` Brijesh Singh
2017-08-03 14:15   ` Laszlo Ersek
2017-08-05  1:25   ` 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=294adc6a-1eb7-3ce2-6ae5-15392826fe54@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