Re: Problem with x32 pointer_guard

[Roland McGrath <roland at hack dot frob dot com>]

> sysdeps/x86_64/__longjmp.S has
> 
> ENTRY(__longjmp)
> 	/* Restore registers.  */
> 	mov (JB_RSP*8)(%rdi),%R8_LP
> 	movq (JB_RBP*8)(%rdi),%r9
> 	mov (JB_PC*8)(%rdi),%RDX_LP
> #ifdef PTR_DEMANGLE
> 	PTR_DEMANGLE (%R8_LP)
> 	PTR_DEMANGLE (%r9)
> 	PTR_DEMANGLE (%RDX_LP)
> #endif

We're treating %rbp differently here because it's not necessarily, or
even usually, a pointer.  Frankly, I think we could just drop the
mangling for %rbp.  In production code, it won't be a frame pointer.

If we do want to keep mangling %rbp, then it's really not pointer
mangling.  It's register mangling.  Arguably we might as well apply it
to all the registers, though perhaps that makes it easier for an
attacker to discover the guard value since it's probably very easy to
arrange that certain registers (like the argument-passing ones) are
known to contain zero.

Currently we only actually read sizeof (uintptr_t) random bits to
initialize the guard values.  So IMHO it would be wrong to make the
pointer_guard field wider unless we're really going to set its high
bits.

I would be fine with dropping the mangling of %rbp, which is trivial
to do.

I'd also be fine with adding a few instructions to __sigsetjmp and
__longjmp preserve the high bits of %rbp while mangling the low bits,
which is simple enough.  Given that a couple more integer instructions
in setjmp and longjmp hardly seems like a performance issue, and that
some could make the case for the security-sensitivity of %rbp since
probably a lot of people use -fno-omit-frame-pointer even though it's
not the wisest choice, this seems like the conservative route.
Minimally tested implementation of that is on roland/x32-setjmp-mangle.

I'd also be fine with adding "register-mangling" alongside
"pointer-mangling" and using that here.  That would entail widening
the field (or adding a different one for non-pointers, which seems
questionable since it would have only this one use).

__syscall_long_t is a poor name for the type to use, because this is
really about register size and not about syscall interfaces.  So to do
it right I'd want to add a new internal typedef, even if it would
always match __syscall_long_t on machines we have so far.


Thanks,
Roland