Received: by 2002:a05:6a10:6744:0:0:0:0 with SMTP id w4csp4694565pxu; Wed, 21 Oct 2020 03:00:55 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzsFmxqhdCi4kZUIMYi+PLgiQnQAxXDjZN/iPFd4MJIyV3mRdi4YTsiztKodD0aRVCBfIyj X-Received: by 2002:a17:906:f201:: with SMTP id gt1mr2461949ejb.229.1603274454799; Wed, 21 Oct 2020 03:00:54 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1603274454; cv=none; d=google.com; s=arc-20160816; b=fMhpVzGghZNU/P/Vsp0UDjX9tysPLLLuHqqsiqx11Yj1UnhzH8809I+FjzSVOcDHHK HCz5LTRA0vXktaUjOirS/MTRXgTFsaCUX0r66gxaSHksk8GF7LyuPz/wanRudZwNpnJK 5WhWQsHA3KRH8tZUEGUzQzti1Di9XiA1aw3+vUEZWTL2oyWG9IrW2w0y7Q8OaIsCGKfb 4c5Tx8YczQ79zRc2eIjDpTszdq6OxI9EwpcBZs2v1l9rmCn42pzLVnoQ6xg9oE6uJWIT 8HsbEJ9LBDaiwNFqVKSENQnXiAc1CanosJqQrF29IJGLdW5RneZggGJ+mTUu/vCXvTb4 ey4Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=46RFYozjOUrCT47DTNQygaXDa0U+oyBU4TtGuU6XNI4=; b=y7ycGYOevx/+wZkdvT1NVplGUUB/NSXhF+Yim5zxnRRRGG0SttD2IHg8CUbtPg0aFe NT1Tr8m875vrCwzQc27JcZlTDnkzrWTtdnPzhfy5/cYNF+eoFgCCHu5XeNbYxkvnRqcF 46v1sw0al6Jl0AzNCEgDKI23ot2yiPtjQnMnz8UXDSGcR+nE54ZD35CQr+qo3kC3I1Z1 2eAaIObw8J78zTEm8HkJ6LvlaBGyhZr17ejcOcJtwDlfAGb19jHasL/JiaXfJ23KY4ge sNNlIhjJd42cvvqaX7aADrXuYuHCOE5XXXHKFcdociDrvzBq+/ZK84r3aYkpsJZUXRXW 6xpQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=GCHVRghA; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id jr18si949449ejb.45.2020.10.21.03.00.31; Wed, 21 Oct 2020 03:00:54 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=GCHVRghA; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2409392AbgJTUQ4 (ORCPT + 99 others); Tue, 20 Oct 2020 16:16:56 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:37602 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2409388AbgJTUQz (ORCPT ); Tue, 20 Oct 2020 16:16:55 -0400 Received: from mail-pf1-x443.google.com (mail-pf1-x443.google.com [IPv6:2607:f8b0:4864:20::443]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 9450BC0613D3 for ; Tue, 20 Oct 2020 13:16:55 -0700 (PDT) Received: by mail-pf1-x443.google.com with SMTP id j18so93550pfa.0 for ; Tue, 20 Oct 2020 13:16:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=46RFYozjOUrCT47DTNQygaXDa0U+oyBU4TtGuU6XNI4=; b=GCHVRghA7TeXHOUfpK8XK0MgAeLsh6HEk8QgnUB8L2yCL2zOT3M6p5SwYT0wLxsnKG ZEaY9YWd86FRdLWyCHsCtvol72hfc0jItncd9ghOxvuhpi8g7ugEEtDsTNJ9ogWkSOMX vzJIaSmfV304rau7rEvZ98LpWLIP1sVdgEqEC7xjyMvHub870EJbjSIGnq7B9aYekCa/ a/qBt2p813YIWeNZRHmJcndjfqdAio4yvWkjhGogr1bYvSy/f40UZmiNWh+HOReLSjm2 NDPHNcC8KDwwWadxDamjweTZQ9zPQaOKLMADpJZ752+SomEr6LFbWxOchVr9XxfcMl3c mTmA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=46RFYozjOUrCT47DTNQygaXDa0U+oyBU4TtGuU6XNI4=; b=jsSbz7Eq2vIMc7LIjppBD5dDpeLIrBp8b7KeeP4L0jamm/dOE7cc02k66fPOCa2Vrw yqStjyrjKplLbNfTNz2Ba6rEwufGTDX2S/OoqFeKRhbUIN4dQ48dvtwfUBARfUZlkCF2 ypiwH0DHknmZ0EjtLkYGJAD+bSer6X823IQ8vG/hQPea6mJ+oTWjt8U/MM8UJwCNh7gr 1WEtIh8FgjwkW8xXUlF59aqzxa1m7z5je2jm0/abP7smO+CyJdEzog2kwuQB6t6XD4VY Kb/vNYCN8BHcqcWTdhXZ/J+oEQ8twMWZOGk+OJOr1MWKSEB7aQgKsTh7klioMLdmj6oo G7ZA== X-Gm-Message-State: AOAM531Q3g+PuegBV41CQNkM+bjNTYg3HD782LsLk2rlNU2mZ8EcnJvO ITm5t56ofOrQ8wrGzv1cXCgSk9TZo6GRlBHreOq3IQ== X-Received: by 2002:a63:70d:: with SMTP id 13mr35019pgh.263.1603225014754; Tue, 20 Oct 2020 13:16:54 -0700 (PDT) MIME-Version: 1.0 References: <20201016175339.2429280-1-ndesaulniers@google.com> <160319373854.2175971.17968938488121846972.b4-ty@kernel.org> In-Reply-To: <160319373854.2175971.17968938488121846972.b4-ty@kernel.org> From: Nick Desaulniers Date: Tue, 20 Oct 2020 13:16:43 -0700 Message-ID: Subject: Re: [PATCH] arm64: link with -z norelro regardless of CONFIG_RELOCATABLE To: Will Deacon , Ard Biesheuvel , =?UTF-8?B?RsSBbmctcnXDrCBTw7JuZw==?= , Kees Cook , Dmitry Vyukov , Peter Oberparleiter Cc: Catalin Marinas , kernel-team , LKML , Peter Smith , clang-built-linux , "# 3.4.x" , Linux ARM , Arnd Bergmann Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Oct 20, 2020 at 10:57 AM Will Deacon wrote: > > On Fri, 16 Oct 2020 10:53:39 -0700, Nick Desaulniers wrote: > > With CONFIG_EXPERT=y, CONFIG_KASAN=y, CONFIG_RANDOMIZE_BASE=n, > > CONFIG_RELOCATABLE=n, we observe the following failure when trying to > > link the kernel image with LD=ld.lld: > > > > error: section: .exit.data is not contiguous with other relro sections > > > > ld.lld defaults to -z relro while ld.bfd defaults to -z norelro. This > > was previously fixed, but only for CONFIG_RELOCATABLE=y. > > Applied to arm64 (for-next/core), thanks! > > [1/1] arm64: link with -z norelro regardless of CONFIG_RELOCATABLE > https://git.kernel.org/arm64/c/3b92fa7485eb IF we wanted to go further and remove `-z norelro`, or even enable `-z relro` for aarch64, then we would have to detangle some KASAN/GCOV generated section discard spaghetti. Fangrui did some more digging and found that .fini_array.* sections were relro (read only after relocations, IIUC), so adding them to EXIT_DATA (include/asm-generic/vmlinux.lds.h) was causing them to get included in .exit.data (arch/arm64/kernel/vmlinux.lds.S) making that relro. There's some history here with commits: - e41f501d39126 ("vmlinux.lds: account for destructor sections") - 8dcf86caa1e3da ("vmlinux.lds.h: Fix incomplete .text.exit discards") - d812db78288d7 ("vmlinux.lds.h: Avoid KASAN and KCSAN's unwanted sections") It seems the following works for quite a few different configs/toolchains I played with, but the big IF is whether enabling `-z relro` is worthwhile? If the kernel does respect that mapping, then I assume that's a yes, but I haven't checked yet whether relro is respected within the kernel (`grep -rn RELRO` turns up nothing interesting). I also haven't checked yet whether all supported versions of GNU ld.bfd support -z relro (guessing not, since a quick test warns: `aarch64-linux-gnu-ld: warning: -z relro ignored` for v2.34.90.20200706, may be holding it wrong). (Fangrui also filed https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97507 in regards to GCOV+GCC) diff --git a/include/asm-generic/vmlinux.lds.h b/include/asm-generic/vmlinux.lds.h index cd14444bf600..64578c998e53 100644 --- a/include/asm-generic/vmlinux.lds.h +++ b/include/asm-generic/vmlinux.lds.h @@ -744,7 +744,6 @@ #define EXIT_DATA \ *(.exit.data .exit.data.*) \ - *(.fini_array .fini_array.*) \ *(.dtors .dtors.*) \ MEM_DISCARD(exit.data*) \ MEM_DISCARD(exit.rodata*) @@ -995,6 +994,7 @@ #if defined(CONFIG_KASAN_GENERIC) || defined(CONFIG_KCSAN) # ifdef CONFIG_CONSTRUCTORS # define SANITIZER_DISCARDS \ + *(.fini_array .fini_array.*) \ *(.eh_frame) # else # define SANITIZER_DISCARDS \ @@ -1005,8 +1005,16 @@ # define SANITIZER_DISCARDS #endif +#if defined(CONFIG_GCOV_KERNEL) && defined(CONFIG_CC_IS_GCC) +# define GCOV_DISCARDS \ + *(.fini_array .fini_array.*) +#else +# define GCOV_DISCARDS +#endif + #define COMMON_DISCARDS \ SANITIZER_DISCARDS \ + GCOV_DISCARDS \ *(.discard) \ *(.discard.*) \ *(.modinfo) \ -- Thanks, ~Nick Desaulniers