From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) (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 61BBE2095D214 for ; Wed, 28 Jun 2017 20:31:43 -0700 (PDT) Received: from orsmga004.jf.intel.com ([10.7.209.38]) by fmsmga102.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 28 Jun 2017 20:33:15 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.40,278,1496127600"; d="scan'208";a="102555192" Received: from fmsmsx104.amr.corp.intel.com ([10.18.124.202]) by orsmga004.jf.intel.com with ESMTP; 28 Jun 2017 20:33:15 -0700 Received: from fmsmsx157.amr.corp.intel.com (10.18.116.73) by fmsmsx104.amr.corp.intel.com (10.18.124.202) with Microsoft SMTP Server (TLS) id 14.3.319.2; Wed, 28 Jun 2017 20:33:14 -0700 Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by FMSMSX157.amr.corp.intel.com (10.18.116.73) with Microsoft SMTP Server (TLS) id 14.3.319.2; Wed, 28 Jun 2017 20:33:13 -0700 Received: from shsmsx102.ccr.corp.intel.com ([169.254.2.146]) by SHSMSX151.ccr.corp.intel.com ([169.254.3.56]) with mapi id 14.03.0319.002; Thu, 29 Jun 2017 11:32:54 +0800 From: "Gao, Liming" To: Laszlo Ersek , edk2-devel-01 CC: Ard Biesheuvel , "Justen, Jordan L" Thread-Topic: [PATCH 1/2] OvmfPkg: disable build-time relocation for DXEFV modules Thread-Index: AQHS8FreRUqpa71sbE2heEWWNNg9y6I7KeHA Date: Thu, 29 Jun 2017 03:32:54 +0000 Message-ID: <4A89E2EF3DFEDB4C8BFDE51014F606A14D74FBA1@shsmsx102.ccr.corp.intel.com> References: <20170628220645.26413-1-lersek@redhat.com> <20170628220645.26413-2-lersek@redhat.com> In-Reply-To: <20170628220645.26413-2-lersek@redhat.com> Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.239.127.40] MIME-Version: 1.0 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: Thu, 29 Jun 2017 03:31:43 -0000 Content-Language: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Laszlo: LMFA feature doesn't do PE image rebase at build time. Only XIP module ne= eds to be rebased at build time. LMFA feature will specify the loaded memor= y address for each PE image. At build time, build tool records the memory a= ddress into the one field of PE image. It doesn't rebase PE image. At boot = time, PeiCore/DxeCore/SmmCore will parse PE image, and try to load it at th= e preferred memory address. If the preferred memory address is not availabl= e, PE image will be loaded to other memory address. LMFA feature only suppo= rts the source build EFI image, not support the binary EFI image. This is a= debug feature.=20 For this case, OvmfPkg DXEFV doesn't require to run as XIP. So, it doesn'= t require rebase. I agree this change.=20 Thanks Liming >-----Original Message----- >From: Laszlo Ersek [mailto:lersek@redhat.com] >Sent: Thursday, June 29, 2017 6:07 AM >To: edk2-devel-01 >Cc: Ard Biesheuvel ; Justen, Jordan L >; Gao, Liming >Subject: [PATCH 1/2] OvmfPkg: disable build-time relocation for DXEFV >modules > >When the GenFv utility from BaseTools composes a firmware volume, it >checks whether modules in the firmware volume are subject to build-time >relocation. The primary indication for relocation is whether the firmware >volume has a nonzero base address, according to the [FD] section(s) in the >FDF file that refer to the firmware volume. > >The idea behind build-time relocation is that XIP (execute in place) >modules will not be relocated at boot-time: > >- Pre-DXE phase modules generally execute in place. > > (OVMF is no exception, despite the fact that we have writeable memory > even in SEC: PEI_CORE and PEIMs run in-place from PEIFV, after SEC > decompresses PEIFV and DXEFV from FVMAIN_COMPACT (flash) to RAM. > PEI_CORE and the PEIMs are relocated at boot-time only after PlatformPei > installs the permanent PEI RAM, and the RAM migration occurs.) > >- Modules dispatched by the DXE Core are generally relocated at boot-time. > However, this is not necessarily so, the LMFA (Load Modules at Fixed > Address) feature apparently allows in-place execution for such modules > as well, deriving the load address from the containing firmware volume's > base address at build time. > > (LMFA is controlled by the > gEfiMdeModulePkgTokenSpaceGuid.PcdLoadModuleAtFixAddressEnable >fixed > PCD, which we leave disabled in OVMF.) > >Therefore GenFv relocates even DXE and UEFI driver modules if the >containing firmware volume has a nonzero base address. > >In OVMF, this is the case for both PEIV and DXEFV: > >> [FD.MEMFD] >> BaseAddress =3D $(MEMFD_BASE_ADDRESS) >> Size =3D 0xB00000 >> ErasePolarity =3D 1 >> BlockSize =3D 0x10000 >> NumBlocks =3D 0xB0 >> ... >> 0x020000|0x0E0000 >> >gUefiOvmfPkgTokenSpaceGuid.PcdOvmfPeiMemFvBase|gUefiOvmfPkgToke >nSpaceGuid.PcdOvmfPeiMemFvSize >> FV =3D PEIFV >> >> 0x100000|0xA00000 >> >gUefiOvmfPkgTokenSpaceGuid.PcdOvmfDxeMemFvBase|gUefiOvmfPkgTok >enSpaceGuid.PcdOvmfDxeMemFvSize >> FV =3D DXEFV > >While the build-time relocation certainly makes sense for PEIFV (see >above), the reasons for which we specify DXEFV under [FD.MEMFD] are >weaker: > >- we set the PcdOvmfDxeMemFvBase and PcdOvmfDxeMemFvSize PCDs >here, > >- and we ascertain that DXEFV, when decompressed by SEC from > FVMAIN_COMPACT, will fit into the area allotted here, at build time. > >In other words, the build-time relocation of the modules in DXEFV is a >waste of resources. But, it gets worse: > >Build-time relocation of an executable is only possible if the on-disk and >in-memory layouts are identical, i.e., if the sections of the PE/COFF >image adhere to the same alignment on disk and in memory. Put differently, >the FileAlignment and SectionAlignment headers must be equal. > >For boot-time modules that we build as part of edk2, both alignment values >are 0x20 bytes. For runtime modules that we build as part of edk2, both >alignment values are 0x1000 bytes. This is why the DXEFV relocation, >albeit wasteful, is also successful every time. > >Unfortunately, if we try to include a PE/COFF binary in DXEFV that >originates from outside of edk2, the DXEFV relocation can fail due to the >binary having unmatched FileAlignment and SectionAlignment headers. This >is precisely the case with the E3522X2.EFI network driver for the e1000 >NIC, from Intel's BootUtil / PREBOOT.EXE distribution. > >The solution is to use the FvForceRebase=3DFALSE override under [FV.DXEFV]= . >This tells GenFv not to perform build-time relocation on the firmware >volume, despite the FV having a nonzero base address. As stated above, >this relocation has always been useless and wasteful in OVMF, because we >never enable LMFA. > >(Put differently, E3522X2.EFI could never be loaded from an FV with LMFA >enabled for the platform because E3522X2.EFI has unmatched FileAlignment >and SectionAlignment headers.) > >In DXEFV we also have SMM drivers. Those are relocated at boot-time (into >SMRAM) unconditionally, regardless of LMFA; SMRAM is always discovered at >boot-time. > >Kudos to Ard and Liming for the PE/COFF sections & relocations >explanation, and for the FvForceRebase=3DFALSE tip. > >I regression-tested this change in the following configurations (all with >normal boot and S3 suspend/resume): > > IA32, q35, SMM, Linux > IA32X64, q35, SMM, Linux > IA32X64, q35, SMM, Windows-8.1 > X64, i440fx, no-SMM, Linux > >Cc: Ard Biesheuvel >Cc: Jordan Justen >Cc: Liming Gao >Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3D613 >Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3D615 >Suggested-by: Ard Biesheuvel >Suggested-by: Liming Gao >Contributed-under: TianoCore Contribution Agreement 1.0 >Signed-off-by: Laszlo Ersek >--- > OvmfPkg/OvmfPkgIa32.fdf | 1 + > OvmfPkg/OvmfPkgIa32X64.fdf | 1 + > OvmfPkg/OvmfPkgX64.fdf | 1 + > 3 files changed, 3 insertions(+) > >diff --git a/OvmfPkg/OvmfPkgIa32.fdf b/OvmfPkg/OvmfPkgIa32.fdf >index 09c165882c3f..859457e9aae5 100644 >--- a/OvmfPkg/OvmfPkgIa32.fdf >+++ b/OvmfPkg/OvmfPkgIa32.fdf >@@ -168,6 +168,7 @@ [FV.PEIFV] > >########################################################### >##################### > > [FV.DXEFV] >+FvForceRebase =3D FALSE > FvNameGuid =3D 7CB8BDC9-F8EB-4F34-AAEA-3EE4AF6516A1 > BlockSize =3D 0x10000 > FvAlignment =3D 16 >diff --git a/OvmfPkg/OvmfPkgIa32X64.fdf b/OvmfPkg/OvmfPkgIa32X64.fdf >index 5233314139bc..2a0ed8313786 100644 >--- a/OvmfPkg/OvmfPkgIa32X64.fdf >+++ b/OvmfPkg/OvmfPkgIa32X64.fdf >@@ -168,6 +168,7 @@ [FV.PEIFV] > >########################################################### >##################### > > [FV.DXEFV] >+FvForceRebase =3D FALSE > FvNameGuid =3D 7CB8BDC9-F8EB-4F34-AAEA-3EE4AF6516A1 > BlockSize =3D 0x10000 > FvAlignment =3D 16 >diff --git a/OvmfPkg/OvmfPkgX64.fdf b/OvmfPkg/OvmfPkgX64.fdf >index 36150101e784..ca61fa125795 100644 >--- a/OvmfPkg/OvmfPkgX64.fdf >+++ b/OvmfPkg/OvmfPkgX64.fdf >@@ -168,6 +168,7 @@ [FV.PEIFV] > >########################################################### >##################### > > [FV.DXEFV] >+FvForceRebase =3D FALSE > FvNameGuid =3D 7CB8BDC9-F8EB-4F34-AAEA-3EE4AF6516A1 > BlockSize =3D 0x10000 > FvAlignment =3D 16 >-- >2.13.1.3.g8be5a757fa67 >