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 X-Spam-Level: X-Spam-Status: No, score=-19.4 required=3.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_PATCH,MAILING_LIST_MULTI,MENTIONS_GIT_HOSTING,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED,USER_IN_DEF_DKIM_WL autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id A86C2C388F2 for ; Tue, 20 Oct 2020 20:16:57 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 4DA0A221FC for ; Tue, 20 Oct 2020 20:16:57 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="GCHVRghA" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2409396AbgJTUQ4 (ORCPT ); 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-Google-Smtp-Source: ABdhPJxhzEcDxnQbUj+JT015TazLvxkNXCfo9dZTKFxf4yePhzBsAZxDhe3cue6Irvla0qzlx31G36qNCtX49jixXDk= 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