This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Pointer guard for static binaries?


> It looks like the pointer guard is currently never initialized for static
> binaries.

That is correct.  Note that the way the guard is used, any value like 0 or
garbage is fine and harmless--it just doesn't provide any protection at all
if it's 0, or any protection useful against malice if it never varies.  So,
static binaries built now have now extra protection of this sort than did
static binaries built before.  As you know, there are many ways in which we
don't attempt to have static binaries do as many splefty things as dynamic
linking against libc.so does.  That is to say, this is an oversight that
might as well be intentional.  I'm not at all sure we care to bother that
it get initialized.  But, we do initialize __stack_chk_guard value in
csu/libc-start.c, so we might as well follow suit with __pointer_chk_guard.

> The fallback __pointer_chk_guard is definitely never defined.

There is no "fallback".  What slot is needed or defined differs per machine.
AFAICT, the __pointer_chk_guard symbol is not used by anything at all.

For code inside ld.so itself only, the __pointer_chk_guard_local slot is
used via PIC when PIC is cheap (i.e. x86-64 where it's free).  This is for
use before the thread pointer is set up.  If PIC is not cheap, then no
guard is used inside ld.so and so it goes.  However, I may be missing
something here.  __pointer_chk_guard_local is initialized after the thread
pointer is set up.  So in fact, the early setjmp calls in ld.so before then
are always getting zero.  The only real reason for __pointer_chk_guard_local
in ld.so's (setjmp's) PTR_MANGLE is to have the same setjmp/longjmp code in
ld.so work without crashing (or the overhead of conditionals) both in the early
startup of ld.so (when the guard is uninitialized) and for later calls that
happen after the full setup.  On all other machines so far, ld.so's code
simply disables PTR_MANGLE and there is no actual use of the
__pointer_chk_guard_local slot at all.

> I noticed this trying to define a non-TLS pointer guard on ARM; the primary
> advantage of the TLS pointer guard appears to be efficiency, as far as I can
> tell, and even PIC access is more efficient than TLS access on ARM.

Sorry to be pedantic, but I think it helps here to be precise.  You are not
really talking about TLS per se (which is the ELF thing), but about thread
pointer access.  On other machines, the pointer_guard slot is in tcbhead_t.
Since you do know what you're talking about, I take it that fetching the
thread pointer is what's costly.

On x86 it's certainly the case that thread pointer access is the cheapest
thing to use.  On x86-64 and perhaps some other machines (where PIC access
is via a dedicated register that is always properly preloaded), using PIC
access to a local symbol would be the same (or perhaps cheaper?) as thread
pointer access.  It's not clear to me why x86-64 should put the global
pointer-guard value in tcbhead_t, given that's it's only used in libc.so
and so a local symbol there could be used.  (This would require libc.so's
initialization code to copy the ld.so slot into the libc.so local slot, but
would not require copying the slot into either the initial thread's or all
new threads' tcbhead_t slots.)  I suspect it was just easiest to do it one
way for x86 and then make others be similar to that.

For a particular machine, if it is more efficient overall to keep the
pointer-guard and/or stack-guard values in special globals than in
tcbhead_t, then that's what that machine should do.  (Ideally, such globals
would go in relro space, though that would take some more hackery.)  For
the stack-guard slot, this is unlikely to be the right thing since the
compiler generates accesses to this slot and needs to be able to emit the
same magic for code to be linked into whatever applications or DSOs.


Thanks,
Roland



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]