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-01 <edk2-devel@lists.01.org>
Cc: brijesh.singh@amd.com, Ard Biesheuvel <ard.biesheuvel@linaro.org>,
	Jordan Justen <jordan.l.justen@intel.com>,
	Tom Lendacky <thomas.lendacky@amd.com>
Subject: Re: [PATCH 10/12] OvmfPkg/IoMmuDxe: implement in-place decryption/encryption for Map/Unmap
Date: Wed, 2 Aug 2017 18:01:28 -0500	[thread overview]
Message-ID: <560549ae-700a-2a1c-db97-0851d3a12fe1@amd.com> (raw)
In-Reply-To: <20170802212453.19221-11-lersek@redhat.com>



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

If this is legal then we may need to build MapInfo during
AllocateBuffer() to locate the "StashBuffer". So far, I have not came
across this usecase but I wanted to check with you so that we don't fail
on corner cases. Good part if you have ASSERT() so we should be able to
catch them (if any).

> +    ASSERT (CommonBufferHeader->Signature == COMMON_BUFFER_SIG);
> +    CopyMem (
> +      CommonBufferHeader->StashBuffer,
> +      (VOID *)(UINTN)MapInfo->CryptedAddress,
> +      MapInfo->NumberOfBytes
> +      );
> +    //
> +    // Point "DecryptionSource" to the stash buffer so that we decrypt
> +    // it to the original location, after the switch statement.
> +    //
> +    DecryptionSource = CommonBufferHeader->StashBuffer;
> +    break;
>  
[Snip]



  reply	other threads:[~2017-08-02 22:59 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 [this message]
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
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=560549ae-700a-2a1c-db97-0851d3a12fe1@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