From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <lersek@redhat.com>
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 7F50421BADAAB
for <edk2-devel@lists.01.org>; Sat, 1 Jul 2017 13:34:40 -0700 (PDT)
Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com
[10.5.11.16])
(using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits))
(No client certificate requested)
by mx1.redhat.com (Postfix) with ESMTPS id 43CA18553D;
Sat, 1 Jul 2017 20:36:15 +0000 (UTC)
DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 43CA18553D
Authentication-Results: ext-mx04.extmail.prod.ext.phx2.redhat.com;
dmarc=none (p=none dis=none) header.from=redhat.com
Authentication-Results: ext-mx04.extmail.prod.ext.phx2.redhat.com;
spf=pass smtp.mailfrom=lersek@redhat.com
DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com 43CA18553D
Received: from lacos-laptop-7.usersys.redhat.com (ovpn-116-56.phx2.redhat.com
[10.3.116.56])
by smtp.corp.redhat.com (Postfix) with ESMTP id 2F8F969504;
Sat, 1 Jul 2017 20:36:13 +0000 (UTC)
To: "Gao, Liming" <liming.gao@intel.com>,
edk2-devel-01 <edk2-devel@lists.01.org>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>,
"Justen, Jordan L" <jordan.l.justen@intel.com>
References: <20170628220645.26413-1-lersek@redhat.com>
<20170628220645.26413-2-lersek@redhat.com>
<4A89E2EF3DFEDB4C8BFDE51014F606A14D74FBA1@shsmsx102.ccr.corp.intel.com>
From: Laszlo Ersek <lersek@redhat.com>
Message-ID: <1990275e-e537-54c9-cbc3-2712c4abcbcc@redhat.com>
Date: Sat, 1 Jul 2017 22:36:13 +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: <4A89E2EF3DFEDB4C8BFDE51014F606A14D74FBA1@shsmsx102.ccr.corp.intel.com>
X-Scanned-By: MIMEDefang 2.79 on 10.5.11.16
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16
(mx1.redhat.com [10.5.110.28]); Sat, 01 Jul 2017 20:36:15 +0000 (UTC)
Subject: Re: [PATCH 1/2] OvmfPkg: disable build-time relocation for DXEFV modules
X-BeenThere: edk2-devel@lists.01.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: EDK II Development <edk2-devel.lists.01.org>
List-Unsubscribe: <https://lists.01.org/mailman/options/edk2-devel>,
<mailto:edk2-devel-request@lists.01.org?subject=unsubscribe>
List-Archive: <http://lists.01.org/pipermail/edk2-devel/>
List-Post: <mailto:edk2-devel@lists.01.org>
List-Help: <mailto:edk2-devel-request@lists.01.org?subject=help>
List-Subscribe: <https://lists.01.org/mailman/listinfo/edk2-devel>,
<mailto:edk2-devel-request@lists.01.org?subject=subscribe>
X-List-Received-Date: Sat, 01 Jul 2017 20:34:40 -0000
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Liming,
On 06/29/17 05:32, Gao, Liming wrote:
> Laszlo:
> LMFA feature doesn't do PE image rebase at build time. Only XIP
> module needs to be rebased at build time.
Thank you for the clarification.
In this case, BaseTools/GenFv has a bug.
Namely, if LMFA does not need build-time relocation for DXE-phase
modules, then *what exactly* needs build-time relocation for DXE-phase
modules?
This is the code in "BaseTools/Source/C/GenFv/GenFvInternalLib.c":
3537 case EFI_FV_FILETYPE_DRIVER:
3538 case EFI_FV_FILETYPE_DXE_CORE:
3539 //
3540 // Check if section-alignment and file-alignment match or not
3541 //
3542 if ((ImgHdr->Pe32.OptionalHeader.SectionAlignment != ImgHdr->Pe32.OptionalHeader.FileAlignment)) {
3543 //
3544 // Xip module has the same section alignment and file alignment.
3545 //
3546 Error (NULL, 0, 3000, "Invalid", "Section-Alignment and File-Alignment do not match : %s.", FileName);
3547 return EFI_ABORTED;
3548 }
3549 NewPe32BaseAddress = XipBase + (UINTN) CurrentPe32Section.Pe32Section + CurSecHdrSize - (UINTN)FfsFile;
3550 break;
According to the Platform Init 1.6 spec,
- 2.1.4.1 Firmware File Types:
[...] the type EFI_FV_FILETYPE_DRIVER indicates that the file is a DXE
driver and is interesting to the DXE Dispatcher.
- 2.1.4.1.4 EFI_FV_FILETYPE_DRIVER:
The file type EFI_FV_FILETYPE_DRIVER denotes a file that contains a
PE32 image that can be dispatched by the DXE Dispatcher.
So, *when exactly* is it the case that a module dispatched by the DXE
core *needs* build-time relocation?
I claim that the answer is "never", and therefore the above code is a
bug in BaseTools/GenFv.
I thought that this build-time relocation was needed by the LMFA
feature, but you confirmed above that LMFA does not need it. So, it
looks like *nothing at all* needs build-time relocation for
EFI_FV_FILETYPE_DRIVER, because the modules dispatched by the DXE core
are *never* XIP modules.
Do you agree?
> For this case, OvmfPkg DXEFV doesn't require to run as XIP. So, it
> doesn't require rebase. I agree this change.
This change (for the OVMF FDF files) is only valid if the above
BaseTools/GenFv code is also valid. In other words, *if* there is at
least one valid reason for rebasing DXE modules at build-time.
If there is *no* such reason, then the OVMF FDF files do not need this
change, and GenFv must be fixed instead.
So: if LMFA is *not* the one reason that justifies the rebasing for
EFI_FV_FILETYPE_DRIVER, then *what* is the reason? In my commit message
for the OVMF FDF change, I have to refer to that exact reason.
Thanks
Laszlo