Re: Problem with x32 pointer_guard

["H.J. Lu" <hjl dot tools at gmail dot com>]

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.
>
>

Roland, I will leave it to you.  Thanks.



-- 
H.J.