Problem with x32 pointer_guard

[H.J. Lu]

On Fri, May 18, 2012 at 3:33 PM, Roland McGrath <roland@hack.frob.com> wrote:
>> 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.
>

A patch was posted at

http://sourceware.org/ml/libc-alpha/2012-05/msg01268.html


-- 
H.J.