From: Fangrui Song <maskray@google.com>
To: Szabolcs Nagy <szabolcs.nagy@arm.com>
Cc: libc-alpha@sourceware.org
Subject: Re: [PATCH v2] elf: Remove ELF_RTYPE_CLASS_EXTERN_PROTECTED_DATA
Date: Wed, 1 Jun 2022 00:34:23 -0700 [thread overview]
Message-ID: <20220601073423.ddyb5wuwlo6tpisk@google.com> (raw)
In-Reply-To: <YpcUo9XbORzAH01e@arm.com>
On 2022-06-01, Szabolcs Nagy wrote:
>The 05/31/2022 21:50, Fangrui Song wrote:
>> If an executable has copy relocations for extern protected data, that
>> can only work if the library containing the definition is built with
>> assumptions (a) the compiler emits GOT-generating relocations (b) the
>> linker produces R_*_GLOB_DAT instead of R_*_RELATIVE. Otherwise the
>> library uses its own definition directly and the executable accesses a
>> stale copy. Note: the GOT relocations defeat the purpose of protected
>> visibility as an optimization, but allow rtld to make the executable and
>> library use the same copy when copy relocations are present, but it
>> turns out this never worked perfectly.
>>
>> ELF_RTYPE_CLASS_EXTERN_PROTECTED_DATA has strange semantics when both
>> a.so and b.so define protected var and the executable copy relocates
>> var: b.so accesses its own copy even with GLOB_DAT. The behavior change
>> is from commit 62da1e3b00b51383ffa7efc89d8addda0502e107 (x86) and then
>> copied to nios2 (ae5eae7cfc9c4a8297ff82ec6b794faca1976ecc) and arc
>> (0e7d930c4c11de896fe807f67fa1eb756c9c1e05).
>>
>> Without ELF_RTYPE_CLASS_EXTERN_PROTECTED_DATA, b.so accesses the copy
>> relocated data like a.so.
>>
>> It's extremely unlikely anyone relies on the
>> ELF_RTYPE_CLASS_EXTERN_PROTECTED_DATA behavior, so let's remove it.
>>
>> --
>> Changes from v1:
>> * Reword commit message as suggested by Szabolcs Nagy
>
>Please document the interposition change or fix it.
Does this paragraph count as an explanation?
"Without ELF_RTYPE_CLASS_EXTERN_PROTECTED_DATA, b.so accesses the copy relocated data like a.so."
Or, what other documentation on the interposition behavior do you expect?
>That is important as it affects binaries without copy relocation.
next prev parent reply other threads:[~2022-06-01 7:34 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-06-01 4:50 Fangrui Song
2022-06-01 7:26 ` Szabolcs Nagy
2022-06-01 7:34 ` Fangrui Song [this message]
2022-06-01 9:53 ` Szabolcs Nagy
2022-06-01 10:56 ` Florian Weimer
2022-06-02 5:21 ` Fangrui Song
2022-06-01 17:56 ` [PATCH v3] " Fangrui Song
2022-06-07 13:24 ` Szabolcs Nagy
2022-06-07 17:49 ` Fangrui Song
2022-06-08 9:15 ` Szabolcs Nagy
2022-06-08 17:16 ` Fangrui Song
2022-06-09 8:12 ` Szabolcs Nagy
2022-06-07 17:49 ` H.J. Lu
2022-06-07 18:21 ` Fangrui Song
2022-06-07 19:21 ` H.J. Lu
2022-06-07 20:00 ` Fangrui Song
2022-06-07 21:02 ` H.J. Lu
2022-06-07 23:57 ` Fangrui Song
2022-06-08 1:51 ` H.J. Lu
2022-06-08 3:42 ` Fangrui Song
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=20220601073423.ddyb5wuwlo6tpisk@google.com \
--to=maskray@google.com \
--cc=libc-alpha@sourceware.org \
--cc=szabolcs.nagy@arm.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).