From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 73570C433F5 for ; Thu, 28 Apr 2022 02:41:49 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:Content-Type: Content-Transfer-Encoding:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References:Message-ID: Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=6A4Tw6R83LWhk0Mt9bFkIv2FVbJErSzPAfhwrqbopAo=; b=W6M2nPyEKncqIUhOrblHMy4n5G 3/5L/b2EKrrI7TtP5M6EEqXVrBx2P91lH1Xza787JU4xZQrqxtF2hWV3heWTdRQI6gH8h02GFGdzx wM6LqBK5/3SMhcnXwyokOjgmom6x3CreuW9purGNYQwmB96f6OWluygGOQa/bnGAilYYkOAN+AaiB QAJ7vkF+gBDLE54XDb0exiwQcSV7Zu/B9a/cyY6ScNH+f3GxeD4n7nXsTaa8LFyxMZYBGn5k2c6Y3 trvtsVQ3zIEp7UEm8HdwN4l9y5R9rghOHN/Y0fB4HTY0kT57EKIKj8WvSajlI1us5v95M0mJihlRm 8uyM+MgQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1nju5F-004QLP-CR; Thu, 28 Apr 2022 02:40:45 +0000 Received: from mail-pl1-x634.google.com ([2607:f8b0:4864:20::634]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1nju5B-004QKS-U8 for linux-arm-kernel@lists.infradead.org; Thu, 28 Apr 2022 02:40:43 +0000 Received: by mail-pl1-x634.google.com with SMTP id q8so3155421plx.3 for ; Wed, 27 Apr 2022 19:40:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=1S132FtdDmdc4cHE8X/HeLW8XsH3VQUAfBpB17jqPrQ=; b=PCfCRwFzpD/rj7ke78iKnrOOuUI4bIsU+800qOf7KWCjfDxOPqsihUFjG1pHLWwzX1 ef/PxTJteYGpPmNry8Hp4owAfoN762Vp9MscJXWPWD7AbOzWtbllRvQe43eXUHpLNTAU Q/Cu14DAG/F27sV0CEq2X6iBnKm3wNZS/Nt4n0/N5k7bf6k0CWKcRtIOet4gWlLJMfi0 63FRfcg9hV3is2eeikZIBZ3CSt9tOzhjBP7AU4r3uFZX/9wlk1UsAF/anJeWAQ1o04wM b7bgrJejTdkczNsIHwetfbIedAMTTufmuN38cHlB0IHyH2v8bbGRhbVv23TRA36DanPb P+NA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=1S132FtdDmdc4cHE8X/HeLW8XsH3VQUAfBpB17jqPrQ=; b=UpGWBOn2bIJ35pzPqBJLLGYv1LnPC+Ua0i6XOnoupSAh3KBte9eDmvIkLO00cAzN96 +aek5uEq1O1BNVoKmIloL7VTm36vrdpMqr9VL5ocbsoJo9HU0VMMdcFCxDs/PH/imdgW 4wxPDdaFAx2uJxMb+JD09NRlr5qAUHMsdwhXgqsntbpZbWtni/xEJ4UcAWxaVvITUjv0 xPnZBUBHvl/ic2SpeicTxpdDC1VH4EV08zUhCXAOo8mF8zGKoV1mvF4oBPWuijFcLuxF 42PThEEwB2E8v08FkQeUTLMFTabZMXV2bUZck8glGNpn7s/tP87WICc+T2K3fv+c+Bp7 UD6A== X-Gm-Message-State: AOAM5324k2HNHg0Md/nwkkysoq1yl5Ri09Rre3p2yYwiI7cA/xZIjK5M AYPsG98TZUGfFwSky7PFooIycw== X-Google-Smtp-Source: ABdhPJykVfGV6+2U8N4bEwO5WaDTlyaqTwfciGOXVdAz2OMbUZh8Ce95YBqyKXTmsEbf82WnjWQolw== X-Received: by 2002:a17:903:14a:b0:15c:f657:62cd with SMTP id r10-20020a170903014a00b0015cf65762cdmr22830900plc.36.1651113635689; Wed, 27 Apr 2022 19:40:35 -0700 (PDT) Received: from google.com ([2620:15c:2ce:200:97d8:6a3e:53c0:230d]) by smtp.gmail.com with ESMTPSA id g13-20020a62520d000000b0050a923a7754sm19975656pfb.119.2022.04.27.19.40.34 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 27 Apr 2022 19:40:35 -0700 (PDT) Date: Wed, 27 Apr 2022 19:40:30 -0700 From: Fangrui Song To: Ard Biesheuvel Cc: linux-arm-kernel@lists.infradead.org, clang-built-linux@googlegroups.com, will@kernel.org, catalin.marinas@arm.com, keescook@chromium.org, mark.rutland@arm.com, nathan@kernel.org, Sami Tolvanen , Nick Desaulniers Subject: Re: [RFC PATCH 2/2] arm64: kernel: switch to PIE code generation for relocatable kernels Message-ID: <20220428024030.gwxb746c5gwvcnw6@google.com> References: <20220427171241.2426592-1-ardb@kernel.org> <20220427171241.2426592-3-ardb@kernel.org> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20220427171241.2426592-3-ardb@kernel.org> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220427_194042_030521_E4176B78 X-CRM114-Status: GOOD ( 24.74 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On 2022-04-27, Ard Biesheuvel wrote: >We currently use ordinary, position dependent code generation for the >core kernel, which happens to default to the 'small' code model on both >GCC and Clang. This is the code model that relies on ADRP/ADD or >ADRP/LDR pairs for symbol references, which are PC-relative with a range >of -/+ 4 GiB, and therefore happen to be position independent in >practice. > >This means that the fact that we can link the relocatable KASLR kernel >using the -pie linker flag (which generates the runtime relocations and >inserts them into the binary) is somewhat of a coincidence, and not >something which is explicitly supported by the toolchains. Agree. The current -fno-PIE + -shared -Bsymbolic combo works as a conincidence, not guaranteed by the toolchain. -shared needs -fpic object files. -shared -Bsymbolic is very similar to -pie and therefore works with -fpie object files, but the usage is not recommended from the toolchain perspective. >The reason we have not used -fpie for code generation so far (which is >the compiler flag that should be used to generate code that is to be >linked with -pie) is that by default, it generates code based on >assumptions that only hold for shared libraries and PIE executables, >i.e., that gathering all relocatable quantities into a Global Offset >Table (GOT) is desirable because it reduces the CoW footprint, and >because it permits ELF symbol preemption (which lets an executable >override symbols defined in a shared library, in a way that forces the >shared library to update all of its internal references as well). >Ironically, this means we end up with many more absolute references that >all need to be fixed up at boot. This is not about symbol preemption (when the executable and a shared objectdefine the same symbol, which one wins). An executable using a GOT which will be resolved to a shared object => this is regular relocation resolving and there is no preemption. It is that the compiler prefers code generation which can avoid text relocations / copy relocations / canonical PLT entries (https://maskray.me/blog/2021-01-09-copy-relocations-canonical-plt-entries-and-protected#summary). >Fortunately, we can convince the compiler to handle this in a way that >is a bit more suitable for freestanding binaries such as the kernel, by >setting the 'hidden' visibility #pragma, which informs the compiler that >symbol preemption or CoW footprint are of no concern to us, and so >PC-relative references that are resolved at link time are perfectly >fine. Agree >So let's enable this #pragma and build with -fpie when building a >relocatable kernel. This also means that all constant data items that >carry statically initialized pointer variables are now emitted into the >.data.rel.ro* sections, so move these into .rodata where they belong. LGTM, except: is ".rodata" a typo? The patch doesn't reference .rodata >Code size impact (GCC): > >Before: > > text data bss total filename > 16712396 18659064 534556 35906016 vmlinux > >After: > > text data bss total filename > 16804400 18612876 534556 35951832 vmlinux > >Code size impact (Clang): > >Before: > > text data bss total filename > 17194584 13335060 535268 31064912 vmlinux > >After: > > text data bss total filename > 17194536 13310032 535268 31039836 vmlinux > >Signed-off-by: Ard Biesheuvel >--- > arch/arm64/Makefile | 4 ++++ > arch/arm64/kernel/vmlinux.lds.S | 9 ++++----- > 2 files changed, 8 insertions(+), 5 deletions(-) > >diff --git a/arch/arm64/Makefile b/arch/arm64/Makefile >index 2f1de88651e6..94b6c51f5de6 100644 >--- a/arch/arm64/Makefile >+++ b/arch/arm64/Makefile >@@ -18,6 +18,10 @@ ifeq ($(CONFIG_RELOCATABLE), y) > # with the relocation offsets always being zero. > LDFLAGS_vmlinux += -shared -Bsymbolic -z notext \ > $(call ld-option, --no-apply-dynamic-relocs) >+ >+# Generate position independent code without relying on a Global Offset Table >+KBUILD_CFLAGS_KERNEL += -fpie -include $(srctree)/include/linux/hidden.h >+ > endif > > ifeq ($(CONFIG_ARM64_ERRATUM_843419),y) >diff --git a/arch/arm64/kernel/vmlinux.lds.S b/arch/arm64/kernel/vmlinux.lds.S >index edaf0faf766f..b1e071ac1acf 100644 >--- a/arch/arm64/kernel/vmlinux.lds.S >+++ b/arch/arm64/kernel/vmlinux.lds.S >@@ -174,8 +174,6 @@ SECTIONS > KEXEC_TEXT > TRAMP_TEXT > *(.gnu.warning) >- . = ALIGN(16); >- *(.got) /* Global offset table */ > } > > /* >@@ -192,6 +190,8 @@ SECTIONS > /* everything from this point to __init_begin will be marked RO NX */ > RO_DATA(PAGE_SIZE) > >+ .data.rel.ro : ALIGN(8) { *(.got) *(.data.rel.ro*) } >+ > HYPERVISOR_DATA_SECTIONS > > idmap_pg_dir = .; >@@ -273,6 +273,8 @@ SECTIONS > _sdata = .; > RW_DATA(L1_CACHE_BYTES, PAGE_SIZE, THREAD_ALIGN) > >+ .data.rel : ALIGN(8) { *(.data.rel*) } >+ > /* > * Data written with the MMU off but read with the MMU on requires > * cache lines to be invalidated, discarding up to a Cache Writeback >@@ -320,9 +322,6 @@ SECTIONS > *(.plt) *(.plt.*) *(.iplt) *(.igot .igot.plt) > } > ASSERT(SIZEOF(.plt) == 0, "Unexpected run-time procedure linkages detected!") >- >- .data.rel.ro : { *(.data.rel.ro) } >- ASSERT(SIZEOF(.data.rel.ro) == 0, "Unexpected RELRO detected!") > } > > #include "image-vars.h" >-- >2.30.2 > >-- >You received this message because you are subscribed to the Google Groups "Clang Built Linux" group. >To unsubscribe from this group and stop receiving emails from it, send an email to clang-built-linux+unsubscribe@googlegroups.com. >To view this discussion on the web visit https://groups.google.com/d/msgid/clang-built-linux/20220427171241.2426592-3-ardb%40kernel.org. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel