From: Cary Coutant <ccoutant@gmail.com>
To: generic-abi@googlegroups.com
Cc: gnu-gabi@sourceware.org
Subject: Re: RFC: Audit external function called indirectly via GOT
Date: Mon, 01 Jan 2018 00:00:00 -0000 [thread overview]
Message-ID: <CAJimCsHksFELv9xi851jFN6_tdgRTP+8N9OAnZkiGX79phnD+Q@mail.gmail.com> (raw)
In-Reply-To: <20180317133115.GA4681@gmail.com>
> Auditing of external function calls and their return values relies on
> lazy binding with PLT. When external functions are called indirectly
> via GOT without using PLT, auditing stops working.
Could you give a little background here? Why does it stop working?
What does auditing rely on? I didn't find anything about this in the
psABI document.
> Here is a proposal to support auditing of external function called
> indirectly via GOT:
>
> 1. Add optional dynamic tags:
>
> #define DT_GNU_PLT 0x6ffffef4 /* Address of PLT section */
> #define DT_GNU_PLTSZ 0x6ffffdf1 /* Size of PLT section */
> #define DT_GNU_PLTENT 0x6ffffdf2 /* Size of one PLT entry */
> #define DT_GNU_PLT0SZ 0x6ffffdf3 /* Size of the first PLT entry */
> #define DT_GNU_PLTGOTSZ 0x6ffffdf4 /* Size of PLTGOT section */
>
> and update DT_FLAGS_1 with:
>
> #define DF_1_JMPRELIGN 0x10000000 /* DT_JMPREL can be ignored */
> 2. Linker creates PLT entries for auditing external function calls via
> GOT and sets DT_GNU_PLT, DT_GNU_PLTSZ, DT_GNU_PLTENT, DT_GNU_PLT0SZ and
> DT_GNU_PLTGOTSZ. If PLT isn't required for lazy binding, set the
> DF_1_JMPRELIGN bit in DT_FLAGS_1.
> 3. When auditing is enabled at run-time, dynamic linker resolves GLOB_DAT
> relocation to its corresponding PLT entry by finding JUMP_SLOT relocation
> against the same function and use its PLT slot as the function address.
> On x86, the first PLT entry and the 3 GOT slots are reserved. GOT slot
> is (JUMP_SLOT relocation offset - DT_PLTGOT) / size of GOT entry. PLT
> offset is (GOT slot - 3) * DT_GNU_PLTENT + DT_GNU_PLT0SZ. PLT address
> is DT_GNU_PLT + PLT offset. DT_GNU_PLT, DT_GNU_PLTSZ, DT_PLTGOT and
> DT_GNU_PLTGOTSZ can be used to check if GOT and PLT offsets are within
> range.
> 4. If DF_1_JMPRELIGN is set, dynamic linker can ignore DT_JMPREL when
> lazy binding is disabled.
>
> Any comments?
Maybe a little more background would help me understand this better,
but I don't see why the GOT slots aren't being (or couldn't be)
statically relocated to point to the PLT slots. If the linker does
that, all the dynamic loader has to do is ignore the JMPREL
relocations at startup, and let lazy binding happen. I don't see why
it would need to go through this complicated matching process.
(One trivial comment on your choice of naming: I can't see "JMPRELIGN"
without reading it as a misspelled "jump re-align"! Maybe "IGN_JMPREL"
would be better for human readers.)
-cary
next prev parent reply other threads:[~2018-03-21 17:16 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-01-01 0:00 H.J. Lu
2018-01-01 0:00 ` Florian Weimer
2018-01-01 0:00 ` H.J. Lu
2018-01-01 0:00 ` Florian Weimer
2018-01-01 0:00 ` Carlos O'Donell
2018-01-01 0:00 ` Florian Weimer
2018-01-01 0:00 ` Carlos O'Donell
2018-01-01 0:00 ` Florian Weimer
2018-01-01 0:00 ` H.J. Lu
2018-01-01 0:00 ` Florian Weimer
2018-01-01 0:00 ` H.J. Lu
2018-01-01 0:00 ` H.J. Lu
2018-01-01 0:00 ` Carlos O'Donell
2018-01-01 0:00 ` Cary Coutant
2018-01-01 0:00 ` H.J. Lu
2018-01-01 0:00 ` Cary Coutant
2018-01-01 0:00 ` H.J. Lu
2018-01-01 0:00 ` Cary Coutant
2018-01-01 0:00 ` H.J. Lu
2018-01-01 0:00 ` Florian Weimer
2018-01-01 0:00 ` H.J. Lu
2018-01-01 0:00 ` Florian Weimer
2018-01-01 0:00 ` Cary Coutant [this message]
2018-01-01 0:00 ` Carlos O'Donell
2018-01-01 0:00 ` Cary Coutant
2018-01-01 0:00 ` H.J. Lu
2018-01-01 0:00 ` Cary Coutant
2018-01-01 0:00 ` H.J. Lu
2018-01-01 0:00 ` Cary Coutant
2018-01-01 0:00 ` Alan Modra
2018-01-01 0:00 ` H.J. Lu
2018-01-01 0:00 ` Alan Modra
2018-01-01 0:00 ` 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=CAJimCsHksFELv9xi851jFN6_tdgRTP+8N9OAnZkiGX79phnD+Q@mail.gmail.com \
--to=ccoutant@gmail.com \
--cc=generic-abi@googlegroups.com \
--cc=gnu-gabi@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).