public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Fangrui Song <i@maskray.me>
To: Jeff Law <jeffreyalaw@gmail.com>
Cc: Jakub Jelinek <jakub@redhat.com>,
	Andrew Pinski <pinskia@gmail.com>,
	Fangrui Song <maskray@google.com>,
	GCC Patches <gcc-patches@gcc.gnu.org>,
	Jan Hubicka <hubicka@ucw.cz>
Subject: Re: [PATCH] Add --enable-default-semantic-interposition to GCC configure
Date: Mon, 7 Jun 2021 12:01:53 -0700	[thread overview]
Message-ID: <20210607190153.tkl5ga43ckk7vdke@gmail.com> (raw)
In-Reply-To: <20210607181321.GL7746@tucnak>


On 2021-06-07, Jakub Jelinek wrote:
>On Mon, Jun 07, 2021 at 12:01:55PM -0600, Jeff Law via Gcc-patches wrote:
>> > This breaks assumptions across the board.  If software packages want
>> > to use -fno-semantic-interposition that is one thing.  But distros
>> > should not be changing the default.  This is just like using
>> > -ffast-math :).
>> Some distros already force immediate binding at link time for security
>> purposes on a distro-wide basis which, IIUC, does the same thing, but
>> without the benefits from a code generation standpoint.
>
>If you are talking about -Wl,-z,now, that is very different, semantic
>interposition then still works just fine.
>If you are talking about the glibc style by hand "protected" visibility,
>bind calls to symbols defined in the same library through internal symbols,
>then that is done only for a couple of packages and is stronger than
>-fno-semantic-interposition.
>
>	Jakub
>

-fno-semantic-interposition can save a PLT entry (and associated
R_*_JUMP_SLOT dynamic relocation) if a default visibility STB_GLOBAL
function is only called in its defining TU, not by other TUs linked into
the shared object.

This is a subset of the PLT-suppressing optimization if a distribution defaults to ld -Bsymbolic-non-weak-functions
(https://maskray.me/blog/2021-05-16-elf-interposition-and-bsymbolic#the-last-alliance-of-elf-and-men)



Binding definitions in the same component can make software securer.

https://twitter.com/CarlosODonell/status/1400879768028028935
"Disable PRELOAD/AUDIT, which is what I'm going to pursue e.g.  system-wide glibc hardening tunable."
If such a thing is deployed, why cannot a passionate distribution default to gcc -fno-semantic-interposition  and ld -Bsymbolic-non-weak-functions
can bring back the lost performance (15+% for my clang; 27% for cpython; ...)



Last, the "assumption" is just GCC's mapping from source code to the ELF binary
format.
https://maskray.me/blog/2021-05-09-fno-semantic-interposition#source-level-implication
We could also argue that C++ odr rule doesn't like us doing semantic interposition.
(I know it's vague https://stackoverflow.com/questions/55632222/odr-violation-when-linking-static-and-dynamic-library )

      reply	other threads:[~2021-06-07 19:01 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-06 23:12 Fangrui Song
2021-06-06 23:18 ` Andrew Pinski
2021-06-06 23:36   ` Fangrui Song
2021-06-07 18:01   ` Jeff Law
2021-06-07 18:13     ` Jakub Jelinek
2021-06-07 19:01       ` Fangrui Song [this message]

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=20210607190153.tkl5ga43ckk7vdke@gmail.com \
    --to=i@maskray.me \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=hubicka@ucw.cz \
    --cc=jakub@redhat.com \
    --cc=jeffreyalaw@gmail.com \
    --cc=maskray@google.com \
    --cc=pinskia@gmail.com \
    /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).