[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: RFC: Audit external function called indirectly via GOT
> 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
> 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
> 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.)