Retpolines and CFI

[H.J. Lu]

On Thu, Jan 25, 2018 at 12:32 AM, Florian Weimer <fweimer@redhat.com> wrote:
> 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.

Can you open a GCC bug to track it?

Thanks.

-- 
H.J.