Retpolines and CFI

Florian Weimer fweimer@redhat.com
Thu Jan 25 08:40:00 GMT 2018


On 01/22/2018 01:21 PM, Florian Weimer wrote:

> There is a different issue with the think itself.
> 
> __x86_indirect_thunk_rax:
> .LFB2:
>          .cfi_startproc
>          call    .LIND5
> .LIND4:
>          pause
>          lfence
>          jmp     .LIND4
> .LIND5:
>          mov     %rax, (%rsp)
>          ret
>          .cfi_endproc
> 
> If a signal is delivered after the mov has executed, the unwinder will 
> eventually unwind through the signal frame and hit 
> __x86_indirect_thunk_rax.  It does not treat it as a signal frame, so 
> the return address of the stack is decremented by one, in an attempt to 
> obtain a program counter value which is within the call instruction. 
> However, in this scenario, the return address is actually the start of 
> the function, and subtracting one moves the program counter out of the 
> unwind region for that function.

I think it is possible to fix the second case by hiding the the return 
address at the top of the stack, like this:

__x86_indirect_thunk_rax:
.LFB2:
         .cfi_startproc
         call    .LIND5
.LIND4:
         pause
         lfence
         jmp     .LIND4
.LIND5:
         .cfi_def_cfa_offset 16
         mov     %rax, (%rsp)
         ret
         .cfi_endproc

The unwinder should then use the other return address, from the caller 
of the thunk routine.

Thanks,
Florian



More information about the Gcc mailing list