public inbox for libc-alpha@sourceware.org
 help / color / mirror / Atom feed
From: "H.J. Lu" <hjl.tools@gmail.com>
To: Adhemerval Zanella <adhemerval.zanella@linaro.org>
Cc: Siddhesh Poyarekar <siddhesh@sourceware.org>,
	GNU C Library <libc-alpha@sourceware.org>,
	 Florian Weimer <fweimer@redhat.com>,
	Sergei Trofimovich <slyfox@gentoo.org>
Subject: Re: [PATCH 1/3] Add inhibit_stack_protector to ifuncmain9 [BZ #25680]
Date: Fri, 12 Mar 2021 11:55:18 -0800	[thread overview]
Message-ID: <CAMe9rOqJz+N=Z=bmpW1=7mQh+KYXFtFXhDLTAWYinr2G9L6K7Q@mail.gmail.com> (raw)
In-Reply-To: <93d85ab8-071f-50b0-f56c-cc10e6b6e206@linaro.org>

On Fri, Mar 12, 2021 at 10:29 AM Adhemerval Zanella via Libc-alpha
<libc-alpha@sourceware.org> wrote:
>
>
>
> On 12/03/2021 05:52, Siddhesh Poyarekar wrote:
> > On 3/10/21 6:20 PM, Adhemerval Zanella via Libc-alpha wrote:
> >>
> >>
> >> On 10/03/2021 07:13, Siddhesh Poyarekar via Libc-alpha wrote:
> >>> From: David Hughes <davidhughes205@gmail.com>
> >>>
> >>> Enabling --enable-stack-protector=all causes the following tests to fail:
> >>>
> >>>      FAIL: elf/ifuncmain9picstatic
> >>>      FAIL: elf/ifuncmain9static
> >>>
> >>> Nick Alcock (who committed the stack protector code) marked the IFUNC
> >>> resolvers with inhibit_stack_protector when he done the original work and
> >>> suggested doing so again @ BZ #25680. This patch adds
> >>> inhibit_stack_protector to ifuncmain9.
> >>>
> >>> After patch is applied, --enable-stack-protector=all does not fail the
> >>> above tests.
> >>
> >> The BZ#25680 report makes me wonder if would be better to just disable
> >> --enable-stack-protector=all on architecture with IFUNC for now.
> >> This fix the issue on glibc testsuite, but it might still trigger
> >> by users if this same trick is not used (as noted by Sergei).
> >
> > The general problem is that it is at best pointless to add stack protector prologue/epilogue to ifunc resolver functions in static binaries.  On x86_64 it is visible because it results in a crash due to TLS segment register %fs not being set up but elsewhere, the stack chk guard is zero, which makes the dereference safe, but useless.  On ppc64le, the TLS setup happens first, thus avoiding the crash and behaving like the other non-TLS stack_chk_guard architectures.
> >
> > One way to make it not crash on x86_64 could be to delay ifunc resolution (which would then mean making sure that TLS doesn't use ifunc'd functions, e.g. memcpy) and bring it on par with the rest of the architectures.
>
> Is it something preventing us to make x86 follows other architectures in this
> regard?
>

On x86-64, IFUNC was disabled in ld.so before.   Now IFUNC is selectly
enabled in ld.so.
If you want to disable one specific IFUNC in ld.so on x86-64, please
open a glibc bug and
CC me.

-- 
H.J.

  reply	other threads:[~2021-03-12 19:55 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-10 10:13 [PATCH v2 0/3] Clean up stack-protector-all build Siddhesh Poyarekar
2021-03-10 10:13 ` [PATCH 1/3] Add inhibit_stack_protector to ifuncmain9 [BZ #25680] Siddhesh Poyarekar
2021-03-10 12:50   ` Adhemerval Zanella
2021-03-12  8:52     ` Siddhesh Poyarekar
2021-03-12 17:34       ` Adhemerval Zanella
2021-03-12 19:55         ` H.J. Lu [this message]
2021-03-13  6:01           ` Siddhesh Poyarekar
2021-03-13 13:44             ` H.J. Lu
2021-03-13  6:07         ` Siddhesh Poyarekar
2021-03-15 13:58           ` Adhemerval Zanella
2021-03-15 16:34             ` Siddhesh Poyarekar
2021-03-15 13:59   ` Adhemerval Zanella
2021-03-10 10:13 ` [PATCH 2/3] Build get-cpuid-feature-leaf.c without stack-protector [BZ #27555] Siddhesh Poyarekar
2021-03-15 13:59   ` Adhemerval Zanella
2021-03-10 10:14 ` [PATCH 3/3] Build libc-start with stack protector for SHARED Siddhesh Poyarekar
2021-03-15 14:00   ` Adhemerval Zanella

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='CAMe9rOqJz+N=Z=bmpW1=7mQh+KYXFtFXhDLTAWYinr2G9L6K7Q@mail.gmail.com' \
    --to=hjl.tools@gmail.com \
    --cc=adhemerval.zanella@linaro.org \
    --cc=fweimer@redhat.com \
    --cc=libc-alpha@sourceware.org \
    --cc=siddhesh@sourceware.org \
    --cc=slyfox@gentoo.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).