From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from us-smtp-delivery-1.mimecast.com (us-smtp-delivery-1.mimecast.com [205.139.110.61])
 by mx.groups.io with SMTP id smtpd.web09.8453.1581697017062955783
 for <devel@edk2.groups.io>;
 Fri, 14 Feb 2020 08:16:57 -0800
Authentication-Results: mx.groups.io;
 dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=YutFiwIt;
 spf=pass (domain: redhat.com, ip: 205.139.110.61, mailfrom: lersek@redhat.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com;
	s=mimecast20190719; t=1581697016;
	h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
	 to:to:cc:cc:mime-version:mime-version:content-type:content-type:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=57L1LNPVEpqhM+ZOK/nrq5IexK6t8upGMfztaGSMeMU=;
	b=YutFiwIt32tn10dHHTAnVox46qo19I+OAioupNdDumrQiQIAXQWj8iC/N6At71TutFX1bB
	rzUj/2wCUj9NNL70NVrhrxmSJJhUfhKdBPLg8L4wjJasIKuF1ZgklquIkZvCK3SCqpnLZ5
	9e/9YJpn/GYpWgqKBl1QNfy3AaPRUD0=
Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com
 [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id
 us-mta-74-HVt2N9URM5G1SiesvxtCbQ-1; Fri, 14 Feb 2020 11:16:47 -0500
Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11])
	(using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by mimecast-mx01.redhat.com (Postfix) with ESMTPS id A8C74800D4E;
	Fri, 14 Feb 2020 16:16:46 +0000 (UTC)
Received: from lacos-laptop-7.usersys.redhat.com (ovpn-116-153.ams2.redhat.com [10.36.116.153])
	by smtp.corp.redhat.com (Postfix) with ESMTP id 13A7283865;
	Fri, 14 Feb 2020 16:16:45 +0000 (UTC)
Subject: Re: [edk2-devel] OVMF and MEMFD_BASE_ADDRESS values.
To: afish@apple.com
References: <72AA8FEE-8BF3-43D6-9306-A5CDAF855CDA@apple.com>
Cc: devel@edk2.groups.io
From: "Laszlo Ersek" <lersek@redhat.com>
Message-ID: <4be618c2-6c61-35bb-9da1-108a12474bfd@redhat.com>
Date: Fri, 14 Feb 2020 17:16:45 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101
 Thunderbird/52.9.1
MIME-Version: 1.0
In-Reply-To: <72AA8FEE-8BF3-43D6-9306-A5CDAF855CDA@apple.com>
X-Scanned-By: MIMEDefang 2.79 on 10.5.11.11
X-MC-Unique: HVt2N9URM5G1SiesvxtCbQ-1
X-Mimecast-Spam-Score: 0
X-Mimecast-Originator: redhat.com
Content-Language: en-US
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit

Hi Andrew,

On 02/14/20 04:11, Andrew Fish via Groups.Io wrote:
> I'm trying to understand the constraints around the value used with MEMFD_BASE_ADDRESS?
> 
> The reason I'm asking is I've been asked to remove firmware from using lower memory addresses in the low 0x800000 range as it is taking up too many ASLR bits in low memory VMs or some such. 
> 
> At least on my OVMF config that seems to be PcdOvmfLockBoxStorageBase and PcdOvmfPeiMemFvBase. It is easy enough to move MEMFD_BASE_ADDRESS to a much higher address, but I'm not sure if there are any restrictions to the addresses I can use?

TBH I've never researched moving around MEMFD_BASE_ADDRESS. As I stated
earlier, the exact value shouldn't really matter; what matters (i.e.
what various parts of OVMF platform code rely on) is the relative order
of "magic" areas (PCDs etc). We tend to use ASSERT()s to catch problems
in this area, but the coverage may not be complete. So best I can
suggest is, please experiment and see what breaks. (Test S3
suspend/resume too.)

BTW Tom Lendacky's in-progress series

[edk2-devel] [PATCH v4 00/40] SEV-ES guest support
https://edk2.groups.io/g/devel/message/53747
http://mid.mail-archive.com/cover.1580857303.git.thomas.lendacky@amd.com

carves out some more PCDs in the FDF file.

Thanks!
Laszlo