From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: 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 ; 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" , edk2-devel-01 Cc: Ard Biesheuvel , "Justen, Jordan L" References: <20170628220645.26413-1-lersek@redhat.com> <20170628220645.26413-2-lersek@redhat.com> <4A89E2EF3DFEDB4C8BFDE51014F606A14D74FBA1@shsmsx102.ccr.corp.intel.com> From: Laszlo Ersek 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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