[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: RFC: Audit external function called indirectly via GOT

On 03/20/2018 05:52 PM, H.J. Lu wrote:

On Mon, Mar 19, 2018 at 1:21 AM, Florian Weimer <fweimer@redhat.com> wrote:

On 03/17/2018 02:31 PM, H.J. Lu wrote:


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.

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.



Could we ship a template for the PLT entries in ld.so instead?  And if
needed, map it from the file together with an address array, like this?


This won't work since linker needs to know exactly PLT layout to generate
JUMP_SLOT relocations for LD_AUDIT.
I don't see why it would need JUMP_SLOT relocations if it simply auto-generates PLT stub equivalents and installs them in GLOB_DAT relocations. 

Anyway, going back to the larger question what we need here.

I used  this as a test case for audit support with BIND_NOW:

latrace /bin/true --help
Most of Fedora is compiled with BIND_NOW. Fedora 26 does not print latrace messages (the problem I mentioned earlier), Fedora 27 works (yay), Fedora 28 crashes (meh).
So depending on which side Fedora 28+ falls, I think your approach might be viable. I expect that a future binutils version would do this by default, and beyond the additional dynamic section tags, new PLT stubs would only be created for no-plt functions because current binutils is supposed to generate PLT entries again (after they went missing for -z now binaries for some time). 

Thanks,
Florian