Re: [PATCH] kbuild: Always link with '-z norelro'

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxxx> wrote:
> >
> > On Thu, 19 Nov 2020 at 00:05, Nick Desaulniers <ndesaulniers@xxxxxxxxxx> 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



[Index of Archives]     [Linux&nblp;USB Development]     [Linux Media]     [Video for Linux]     [Linux Audio Users]     [Yosemite Secrets]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux