public inbox for libc-alpha@sourceware.org
 help / color / mirror / Atom feed
From: Szabolcs Nagy <szabolcs.nagy@arm.com>
To: Adhemerval Zanella <adhemerval.zanella@linaro.org>
Cc: libc-alpha@sourceware.org
Subject: Re: [PATCH v5 6/7] csu: Move static pie self relocation later [BZ #27072]
Date: Thu, 21 Jan 2021 15:38:03 +0000	[thread overview]
Message-ID: <20210121153802.GI3445@arm.com> (raw)
In-Reply-To: <81d4408b-9f7a-0dec-6ba2-857a74dab73e@linaro.org>

The 01/21/2021 11:07, Adhemerval Zanella wrote:
> 
> 
> On 20/01/2021 12:31, Szabolcs Nagy via Libc-alpha wrote:
> > IFUNC resolvers may depend on tunables and cpu feature setup so
> > move static pie self relocation after those.
> > 
> > It is hard to guarantee that the ealy startup code does not rely
> > on relocations so this is a bit fragile. It would be more robust
> > to handle RELATIVE relocs early and only IRELATIVE relocs later,
> > but the current relocation processing code cannot do that.
> 
> As a side note, how hard would that be? I really think we should aim
> to make the bootstrap less fragile and it would also make porting
> static-pie to other architecture easier.

the IRELATIVE relocs are in the DT_JMPREL area, while RELATIVE
relocs are outside of it. (this split is to allow simpler lazy
binding, i don't know how strictly this is enforced in elf, but
since ifunc is a gnu extension we can just say that this is abi.)

so i think you only have to change/copy elf/dynamic-link.h and
have a ELF_DYNAMIC_RELOCATE variant that processes the two sets
of relocations separately.

if you don't want to rely on DT_JMPREL then i think you have to
change elf/do-rel.h as well to have a elf_dynamic_do_Rel variant
that does IRELATIVE separately.

either case changing these looked more scary to me than the
current patches: likely we have to copy complex logic with slight
modification and there are a lot of things going on there. (but
that was before i learnt about the i386 hidden issue and hidden
weak refs and tunables_strdup.)

> > 
> > The early startup code up to relocation processing includes
> > 
> >   _dl_aux_init (auxvec);
> >   __libc_init_secure ();
> >   __tunables_init (__environ);
> >   ARCH_INIT_CPU_FEATURES ();
> >   _dl_relocate_static_pie ();
> > 
> > These are simple enough that RELATIVE relocs can be avoided.
> > 
> > The following steps include
> > 
> >   ARCH_SETUP_IREL ();
> >   ARCH_SETUP_TLS ();
> >   ARCH_APPLY_IREL ();
> > 
> > On some targets IRELATIVE processing relies on TLS setup on
> > others TLS setup relies on IRELATIVE relocs, so the right
> > position for _dl_relocate_static_pie is target dependent.
> > For now move self relocation as early as possible on targets
> > that support static PIE.
> > 
> > Fixes bug 27072.
> 
> LGTM, thanks.
> 
> Reviewed-by: Adhemerval Zanella  <adhemerval.zanella@linaro.org>

thanks.

  reply	other threads:[~2021-01-21 15:38 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-20 15:29 [PATCH v5 0/7] fix ifunc with static pie " Szabolcs Nagy
2021-01-20 15:30 ` [PATCH v5 1/7] elf: Make the tunable struct definition internal only Szabolcs Nagy
2021-01-20 15:30 ` [PATCH v5 2/7] elf: Avoid RELATIVE relocs in __tunables_init Szabolcs Nagy
2021-01-20 15:30 ` [PATCH v5 3/7] configure: Check for static PIE support Szabolcs Nagy
2021-01-21 13:59   ` Adhemerval Zanella
2021-01-20 15:31 ` [PATCH v5 4/7] csu: Avoid weak ref for __ehdr_start in static PIE Szabolcs Nagy
2021-01-20 15:36   ` H.J. Lu
2021-01-21 14:01   ` Adhemerval Zanella
2021-01-20 15:31 ` [PATCH v5 5/7] Use hidden visibility for early static PIE code Szabolcs Nagy
2021-01-21 14:04   ` Adhemerval Zanella
2021-01-20 15:31 ` [PATCH v5 6/7] csu: Move static pie self relocation later [BZ #27072] Szabolcs Nagy
2021-01-21 14:07   ` Adhemerval Zanella
2021-01-21 15:38     ` Szabolcs Nagy [this message]
2021-01-20 15:31 ` [PATCH v5 7/7] Make libc symbols hidden in static PIE Szabolcs Nagy
2021-01-21 14:10   ` Adhemerval Zanella
2021-01-21 15:44     ` Szabolcs Nagy
2021-01-22  1:25   ` Tulio Magno Quites Machado Filho
2021-01-22  9:41     ` Szabolcs Nagy
2021-01-27  9:44   ` Andreas Schwab

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20210121153802.GI3445@arm.com \
    --to=szabolcs.nagy@arm.com \
    --cc=adhemerval.zanella@linaro.org \
    --cc=libc-alpha@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).