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;
Date:   Thu, 19 Nov 2020 12:33:55 -0700
From:   Nathan Chancellor <natechancellor@gmail.com>
To:     Nick Desaulniers <ndesaulniers@google.com>
Cc:     Ard Biesheuvel <ardb@kernel.org>,
        Masahiro Yamada <masahiroy@kernel.org>,
        Michal Marek <michal.lkml@markovi.net>,
        Catalin Marinas <catalin.marinas@arm.com>,
        Will Deacon <will@kernel.org>,
        Russell King <linux@armlinux.org.uk>,
        Florian Fainelli <f.fainelli@gmail.com>,
        Arnd Bergmann <arnd@arndb.de>,
        Abbott Liu <liuwenliang@huawei.com>,
        Linus Walleij <linus.walleij@linaro.org>,
        Jian Cai <jiancai@google.com>,
        Andrey Ryabinin <aryabinin@virtuozzo.com>,
        Mike Rapoport <rppt@linux.ibm.com>,
        Linux Kbuild mailing list <linux-kbuild@vger.kernel.org>,
        LKML <linux-kernel@vger.kernel.org>,
        Linux ARM <linux-arm-kernel@lists.infradead.org>,
        Fangrui Song <maskray@google.com>,
        Dan Rue <dan.rue@linaro.org>, Mark Brown <broonie@kernel.org>,
        Alan Modra <amodra@gmail.com>
Subject: Re: [PATCH] kbuild: Always link with '-z norelro'
Message-ID: <20201119193355.GA3235069@ubuntu-m3-large-x86>
References: <20201112183839.1009297-1-natechancellor@gmail.com>
 <CAKwvOdkShrqgNDWO0bsPcPZLx-+u79mfmPrGy7CnSKZVdcYzSA@mail.gmail.com>
 <20201113005347.GA3625030@ubuntu-m3-large-x86>
 <CAMj1kXHYG7d-BDtbZ-4+wGdHb0rxXiMLuSvSMW_JFHgp3G6kTg@mail.gmail.com>
 <CAKwvOdk1ir=D---9xVAxcErJWSGVxK1Mv6AC=TK3RVwNdcvFjw@mail.gmail.com>
 <CAKwvOdnauFdUgS0Ww=O-PHrXWhXQEEYd806NUcy8_7MOG0Uo2g@mail.gmail.com>
 <CAMj1kXFrm+M6vN+e8KqBDHxMxSPTaH_hWT2fg+Z3iY3hV4Hcsw@mail.gmail.com>
 <CAKwvOdnNzd6wZoDJEgwjnEuTusU8jUcsLDiYoKipkcTubQ+t5g@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <CAKwvOdnNzd6wZoDJEgwjnEuTusU8jUcsLDiYoKipkcTubQ+t5g@mail.gmail.com>
Precedence: bulk

On Wed, Nov 18, 2020 at 03:24:04PM -0800, Nick Desaulniers wrote:
> On Wed, Nov 18, 2020 at 3:07 PM Ard Biesheuvel <ardb@kernel.org> wrote:
> >
> > On Thu, 19 Nov 2020 at 00:05, Nick Desaulniers <ndesaulniers@google.com> wrote:
> > >
> > > > > > > > To avoid playing whack-a-mole with different architectures over time,
> > > > > > > > hoist '-z norelro' into the main Makefile. This does not affect ld.bfd
> > > > > > > > because '-z norelro' is the default for it.
> > >
> > > Fangrui pointed out off list that this might need an ld-option wrapper
> > > for older versions of GNU binutils.  Dan was showing me some build
> > > logs today, and I thought I spotted such warnings about `-z norelro
> > > will be ignored`.
> >
> > Does ld-option catch options that cause warnings but no errors?
> 
> $ ld.bfd -z foo /dev/null
> ld.bfd: warning: -z foo ignored
> ld.bfd: warning: cannot find entry symbol _start; not setting start address
> ➜ echo $?
> 0
> 
> Probably not. Can be a version check then (yuck); next is to find when
> ld.bfd supported `-z norelro`.
> 
> commit 8c37241be3b1 in binutils looks like it.
> Date:   Tue May 11 17:08:38 2004 +0000
> 
> which looks like either
> 2004-05-17 19:46:23 +0000  (tag: binutils-2_15)
> or
> 2005-05-02 22:04:18 +0000  (tag: binutils-2_16)
> 
> So I think that would be fine then, since the kernel only supports 2.23+.
> 
> Though maybe it's
> commit 5fd104addfddb68844fb8df67be832ee98ad9888
>     Emit a warning when -z relro is unsupported
> 
>     ld silently accepts -z relro and -z norelro for targets that lack the
>     necessary GNU_RELRO support.  This patch makes those targets emit a
>     warning instead, and adds testsuite infrastructure to detect when
>     relro is unsupported.
> 
> So maybe then alpha and xtensa are getting new warnings (IIUC).  If
> that's the case, then we might not be able to set `-z norelro`
> globally, and instead have to play whack a mole per architecture.

Sure, I can just submit the arch/arm patch that I had before this for
now and we can always revisit something like this later, if you feel it
is best.

Cheers,
Nathan