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]
next prev parent 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