From: Szabolcs Nagy <szabolcs.nagy@arm.com>
To: Jann Horn <jannh@google.com>
Cc: Florian Weimer <fweimer@redhat.com>,
oss-security@lists.openwall.com, x86-64-abi@googlegroups.com,
Kernel Hardening <kernel-hardening@lists.openwall.com>
Subject: Re: Alternative CET ABI
Date: Thu, 30 Jul 2020 17:47:14 +0100 [thread overview]
Message-ID: <20200730164713.GF24636@arm.com> (raw)
In-Reply-To: <CAG48ez3OF7DPupKv9mBBKmg-9hDVhVe83KrJ4Jk=CL0nOc7=Jg@mail.gmail.com>
The 07/30/2020 18:41, Jann Horn wrote:
> On Thu, Jul 30, 2020 at 6:02 PM Florian Weimer <fweimer@redhat.com> wrote:
> > Functions no longer start with the ENDBR64 prefix. Instead, the link
> > editor produces a PLT entry with an ENDBR64 prefix if it detects any
> > address-significant relocation for it. The PLT entry performs a NOTRACK
> > jump to the target address. This assumes that the target address is
> > subject to RELRO, of course, so that redirection is not possible.
> > Without address-significant relocations, the link editor produces a PLT
> > entry without the ENDBR64 prefix (but still with the NOTRACK jump), or
> > perhaps no PLT entry at all.
>
> How would this interact with function pointer comparisons? As in, if
> library A exports a function func1 without referencing it, and
> libraries B and C both take references to func1, would they end up
> with different function pointers (pointing to their respective PLT
> entries)? Would this mean that the behavior of a program that compares
ld.so only needs to generate one plt entry
for a function in a process and that entry
can provided the canonical address that is
loaded from some got entry when the address
is used, so there is double indirection, but
it works.
> function pointers obtained through different shared libraries might
> change?
>
> I guess you could maybe canonicalize function pointers somehow, but
> that'd probably at least break dlclose(), right?
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
next prev parent reply other threads:[~2020-07-30 17:27 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-07-30 16:01 Alternative CET ABI Florian Weimer
2020-07-30 16:41 ` Jann Horn
2020-07-30 16:47 ` Szabolcs Nagy [this message]
2020-07-30 16:54 ` Florian Weimer
2020-07-30 17:14 ` H.J. Lu
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=20200730164713.GF24636@arm.com \
--to=szabolcs.nagy@arm.com \
--cc=fweimer@redhat.com \
--cc=jannh@google.com \
--cc=kernel-hardening@lists.openwall.com \
--cc=oss-security@lists.openwall.com \
--cc=x86-64-abi@googlegroups.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 NNTP newsgroup(s).