From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=66.187.233.73; helo=mx1.redhat.com; envelope-from=lersek@redhat.com; receiver=edk2-devel@lists.01.org Received: from mx1.redhat.com (mx3-rdu2.redhat.com [66.187.233.73]) (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 2C998212B9A78 for ; Tue, 12 Jun 2018 11:33:49 -0700 (PDT) Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.rdu2.redhat.com [10.11.54.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 5EE4B818A6AA; Tue, 12 Jun 2018 18:33:48 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-120-239.rdu2.redhat.com [10.10.120.239]) by smtp.corp.redhat.com (Postfix) with ESMTP id 152C620283A3; Tue, 12 Jun 2018 18:33:45 +0000 (UTC) To: Ard Biesheuvel , edk2-devel@lists.01.org Cc: Michael D Kinney , Liming Gao , Ruiyu Ni , Hao Wu , Leif Lindholm , Jordan Justen , Andrew Fish , Star Zeng , Eric Dong , Zenith432 , "Shi, Steven" References: <20180612152306.25998-1-ard.biesheuvel@linaro.org> From: Laszlo Ersek Message-ID: <7be25843-d115-2738-0970-93f05a172aff@redhat.com> Date: Tue, 12 Jun 2018 20:33:45 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <20180612152306.25998-1-ard.biesheuvel@linaro.org> X-Scanned-By: MIMEDefang 2.78 on 10.11.54.6 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.8]); Tue, 12 Jun 2018 18:33:48 +0000 (UTC) X-Greylist: inspected by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.8]); Tue, 12 Jun 2018 18:33:48 +0000 (UTC) for IP:'10.11.54.6' DOMAIN:'int-mx06.intmail.prod.int.rdu2.redhat.com' HELO:'smtp.corp.redhat.com' FROM:'lersek@redhat.com' RCPT:'' Subject: Re: [RFC PATCH 00/11] GCC/X64: use hidden visibility for LTO PIE code X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jun 2018 18:33:49 -0000 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Some super-naive questions, which are supposed to educate me, and not to question the series: On 06/12/18 17:22, Ard Biesheuvel wrote: > The GCC toolchain uses PIE mode when building code for X64, because it > is the most efficient in size: it uses relative references where > possible, but still uses 64-bit quantities for absolute symbol > references, Absolute symbol references such as? References to fixed (constant) addresses? > which is optimal for executables that need to be converted > to PE/COFF using GenFw. Why is that approach optimal? As few relocations records are required as possible? > Enabling PIE mode has a couple of side effects though, primarily caused > by the fact that the primary application area of GCC is to build programs > for userland. GCC will assume that ELF symbols should be preemptible (which > makes sense for PIC but not for PIE, Why don't preemptible symbols make sense for PIE? For example, if a userspace program loads a plugin with dlopen(), and the plugin (.so) uses helper functions from the main executable, then the main executable has to be (well, had to be, earlier?) built with "-rdynamic". Wouldn't this mean the main executable could both be PIE and sensibly have preemptible symbols? (My apologies if I'm disturbingly ignorant about this and the question doesn't even make sense.) > but this simply seems to be the result > of code being shared between the two modes), and it will attempt to keep > absolute references close to each other so that dynamic relocations that > trigger CoW for text pages have the smallest possible footprint. So... Given this behavior, why is it a problem for us? What are the bad symptoms? What is currently broken? Sorry about my naivety here. Thanks, Laszlo > These side effects can be mititgated by overriding the visibility of all > symbol definitions *and* symbol references, using a special #pragma. This > will inform the compiler that symbol preemption and dynamic relocations > are not a concern, and that all symbol references can be emitted as direct > relative references rather than relative references to a GOT entry containing > the absolute address. Unsurprisingly, this leads to better and smaller code. > > Unfortunately, we have not been able to set this override when LTO is in > effect, because the LTO code generator infers from the hidden visibility > of all symbols that none of the code is reachable, and discards it all, > leading to corrupt, empty binaries. > > We can work around this by overriding the visibility for symbols that are > module entry points. So implement this for all occcurrences of the symbol > '_ModuleEntryPoint', and enable 'hidden' visibility in LTO builds as well. > > Note that all the changes in this series resolve to no-ops if USING_LTO > is not #defined. > > Code can be found here: > https://github.com/ardbiesheuvel/edk2/tree/x64-lto-visibility > > Cc: Michael D Kinney > Cc: Liming Gao > Cc: Ruiyu Ni > Cc: Hao Wu > Cc: Leif Lindholm > Cc: Jordan Justen > Cc: Andrew Fish > Cc: Star Zeng > Cc: Eric Dong > Cc: Laszlo Ersek > Cc: Zenith432 > Cc: "Shi, Steven" > > Ard Biesheuvel (11): > MdePkg/ProcessorBind.h: define macro to decorate module entry points > DuetPkg: annotate module entry points with EFI_ENTRYPOINT > EdkCompatibilityPkg: annotate module entry points with EFI_ENTRYPOINT > EmbeddedPkg: annotate module entry points with EFI_ENTRYPOINT > EmulatorPkg: annotate module entry points with EFI_ENTRYPOINT > IntelFrameWorkPkg: annotate module entry points with EFI_ENTRYPOINT > MdeModulePkg: annotate module entry points with EFI_ENTRYPOINT > MdePkg: annotate module entry points with EFI_ENTRYPOINT > Nt32Pkg: annotate module entry points with EFI_ENTRYPOINT > UefiCpuPkg: annotate module entry points with EFI_ENTRYPOINT > MdePkg/ProcessorBind.h X64: drop non-LTO limitation on visiblity > override > > DuetPkg/DxeIpl/DxeInit.c | 1 + > DuetPkg/EfiLdr/EfiLoader.c | 1 + > .../EntryPoints/EdkIIGlueDxeDriverEntryPoint.c | 1 + > .../EntryPoints/EdkIIGluePeimEntryPoint.c | 1 + > .../EntryPoints/EdkIIGlueSmmDriverEntryPoint.c | 1 + > .../Library/EdkIIGlueDxeSmmDriverEntryPoint.h | 1 + > .../Include/Library/EdkIIGluePeimEntryPoint.h | 1 + > .../Library/EdkIIGlueUefiDriverEntryPoint.h | 1 + > EmbeddedPkg/TemplateSec/TemplateSec.c | 1 + > EmulatorPkg/Sec/Sec.c | 1 + > .../DxeSmmDriverEntryPoint/DriverEntryPoint.c | 1 + > MdeModulePkg/Universal/CapsulePei/X64/X64Entry.c | 1 + > MdePkg/Include/Base.h | 7 +++++++ > MdePkg/Include/Library/DxeCoreEntryPoint.h | 1 + > MdePkg/Include/Library/PeiCoreEntryPoint.h | 1 + > MdePkg/Include/Library/PeimEntryPoint.h | 1 + > .../Include/Library/UefiApplicationEntryPoint.h | 1 + > MdePkg/Include/Library/UefiDriverEntryPoint.h | 1 + > MdePkg/Include/X64/ProcessorBind.h | 16 +++++++++++----- > .../DxeCoreEntryPoint/DxeCoreEntryPoint.c | 1 + > .../PeiCoreEntryPoint/PeiCoreEntryPoint.c | 1 + > MdePkg/Library/PeimEntryPoint/PeimEntryPoint.c | 1 + > .../ApplicationEntryPoint.c | 1 + > .../UefiDriverEntryPoint/DriverEntryPoint.c | 1 + > Nt32Pkg/Sec/SecMain.c | 1 + > .../PlatformSecLibNull/PlatformSecLibNull.c | 1 + > 26 files changed, 42 insertions(+), 5 deletions(-) >