New user self-registration is disabled due to spam. For an account please email bugs-admin@lists.llvm.org with your e-mail address and full name.

Bug 45182 - Missing ENDBR at exception landing pad
Summary: Missing ENDBR at exception landing pad
Status: NEW
Alias: None
Product: new-bugs
Classification: Unclassified
Component: new bugs (show other bugs)
Version: trunk
Hardware: PC Linux
: P normal
Assignee: Unassigned LLVM Bugs
URL:
Keywords:
Depends on:
Blocks: release-10.0.0
  Show dependency tree
 
Reported: 2020-03-12 08:06 PDT by H.J. Lu
Modified: 2020-03-23 09:44 PDT (History)
6 users (show)

See Also:
Fixed By Commit(s):


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description H.J. Lu 2020-03-12 08:06:21 PDT
[hjl@gnu-cfl-1 tmp]$ cat x.cc
extern void foo (void);

int
func ()
{
  try {
    foo ();
  }
  catch (int x) {
    return (x != 5);
  }
  return 1;
}
[hjl@gnu-cfl-1 tmp]$ clang -fexceptions  -fcf-protection -O2 -S x.cc -o llvm.s
[hjl@gnu-cfl-1 tmp]$ cat llvm.s
	.text
	.section	.note.gnu.property,"a",@note
	.p2align	3
	.long	4
	.long	16
	.long	5
	.asciz	"GNU"
	.long	3221225474
	.long	4
	.long	3
	.p2align	3
.Lsec_end0:
	.text
	.file	"x.cc"
	.globl	_Z4funcv                # -- Begin function _Z4funcv
	.p2align	4, 0x90
	.type	_Z4funcv,@function
_Z4funcv:                               # @_Z4funcv
.Lfunc_begin0:
	.cfi_startproc
	.cfi_personality 3, __gxx_personality_v0
	.cfi_lsda 3, .Lexception0
# %bb.0:
	endbr64
	pushq	%rbx
	.cfi_def_cfa_offset 16
	.cfi_offset %rbx, -16
	movl	$1, %ebx
.Ltmp0:
	callq	_Z3foov
.Ltmp1:
.LBB0_2:
	movl	%ebx, %eax
	popq	%rbx
	.cfi_def_cfa_offset 8
	retq
.LBB0_1:
	.cfi_def_cfa_offset 16
.Ltmp2:
	movq	%rax, %rdi
	callq	__cxa_begin_catch
	xorl	%ebx, %ebx
	cmpl	$5, (%rax)
	setne	%bl
	callq	__cxa_end_catch
	jmp	.LBB0_2
.Lfunc_end0:
	.size	_Z4funcv, .Lfunc_end0-_Z4funcv
	.cfi_endproc
	.section	.gcc_except_table,"a",@progbits
	.p2align	2
GCC_except_table0:
.Lexception0:
	.byte	255                     # @LPStart Encoding = omit
	.byte	3                       # @TType Encoding = udata4
	.uleb128 .Lttbase0-.Lttbaseref0
.Lttbaseref0:
	.byte	1                       # Call site Encoding = uleb128
	.uleb128 .Lcst_end0-.Lcst_begin0
.Lcst_begin0:
	.uleb128 .Ltmp0-.Lfunc_begin0   # >> Call Site 1 <<
	.uleb128 .Ltmp1-.Ltmp0          #   Call between .Ltmp0 and .Ltmp1
	.uleb128 .Ltmp2-.Lfunc_begin0   #     jumps to .Ltmp2
	.byte	1                       #   On action: 1
	.uleb128 .Ltmp1-.Lfunc_begin0   # >> Call Site 2 <<
	.uleb128 .Lfunc_end0-.Ltmp1     #   Call between .Ltmp1 and .Lfunc_end0
	.byte	0                       #     has no landing pad
	.byte	0                       #   On action: cleanup
.Lcst_end0:
	.byte	1                       # >> Action Record 1 <<
                                        #   Catch TypeInfo 1
	.byte	0                       #   No further actions
	.p2align	2
                                        # >> Catch TypeInfos <<
	.long	_ZTIi                   # TypeInfo 1
.Lttbase0:
	.p2align	2
                                        # -- End function

	.ident	"clang version 9.0.1 (Fedora 9.0.1-2.fc31)"
	.section	".note.GNU-stack","",@progbits
	.addrsig
	.addrsig_sym __gxx_personality_v0
	.addrsig_sym _ZTIi

There is no ENDBR at exception landing pad, which may be reached
via indirect branch, and program will crash on CET enabled machine.

[hjl@gnu-cfl-1 tmp]$ gcc -fexceptions  -fcf-protection -O2 -S x.cc -o gcc.s
[hjl@gnu-cfl-1 tmp]$ cat gcc.s
	.file	"x.cc"
	.text
	.section	.text.unlikely,"ax",@progbits
.LCOLDB0:
	.text
.LHOTB0:
	.p2align 4
	.globl	_Z4funcv
	.type	_Z4funcv, @function
_Z4funcv:
.LFB0:
	.cfi_startproc
	.cfi_personality 0x3,__gxx_personality_v0
	.cfi_lsda 0x3,.LLSDA0
	endbr64
	subq	$24, %rsp
	.cfi_def_cfa_offset 32
.LEHB0:
	call	_Z3foov
.LEHE0:
	movl	$1, %eax
.L1:
	addq	$24, %rsp
	.cfi_remember_state
	.cfi_def_cfa_offset 8
	ret
.L5:
	.cfi_restore_state
	endbr64             <<<<<<<<< ENDBR
	movq	%rax, %rdi
	movq	%rdx, %rax
	jmp	.L2
	.globl	__gxx_personality_v0
	.section	.gcc_except_table,"a",@progbits
	.align 4
.LLSDA0:
	.byte	0xff
	.byte	0x3
	.uleb128 .LLSDATT0-.LLSDATTD0
.LLSDATTD0:
	.byte	0x1
	.uleb128 .LLSDACSE0-.LLSDACSB0
.LLSDACSB0:
	.uleb128 .LEHB0-.LFB0
	.uleb128 .LEHE0-.LEHB0
	.uleb128 .L5-.LFB0
	.uleb128 0x1
.LLSDACSE0:
	.byte	0x1
	.byte	0
	.align 4
	.long	_ZTIi
.LLSDATT0:
	.text
	.cfi_endproc
	.section	.text.unlikely
	.cfi_startproc
	.cfi_personality 0x3,__gxx_personality_v0
	.cfi_lsda 0x3,.LLSDAC0
	.type	_Z4funcv.cold, @function
_Z4funcv.cold:
.LFSB0:
.L2:
	.cfi_def_cfa_offset 32
	subq	$1, %rax
	jne	.L8
	call	__cxa_begin_catch
	cmpl	$5, (%rax)
	setne	%al
	movzbl	%al, %eax
	movl	%eax, 12(%rsp)
	call	__cxa_end_catch
	movl	12(%rsp), %eax
	jmp	.L1
.L8:
.LEHB1:
	call	_Unwind_Resume
.LEHE1:
	.cfi_endproc
.LFE0:
	.section	.gcc_except_table
	.align 4
.LLSDAC0:
	.byte	0xff
	.byte	0x3
	.uleb128 .LLSDATTC0-.LLSDATTDC0
.LLSDATTDC0:
	.byte	0x1
	.uleb128 .LLSDACSEC0-.LLSDACSBC0
.LLSDACSBC0:
	.uleb128 .LEHB1-.LCOLDB0
	.uleb128 .LEHE1-.LEHB1
	.uleb128 0
	.uleb128 0
.LLSDACSEC0:
	.byte	0x1
	.byte	0
	.align 4
	.long	_ZTIi
.LLSDATTC0:
	.section	.text.unlikely
	.text
	.size	_Z4funcv, .-_Z4funcv
	.section	.text.unlikely
	.size	_Z4funcv.cold, .-_Z4funcv.cold
.LCOLDE0:
	.text
.LHOTE0:
	.ident	"GCC: (GNU) 9.2.1 20200123 (Red Hat 9.2.1-3)"
	.section	.note.GNU-stack,"",@progbits
	.section	.note.gnu.property,"a"
	.align 8
	.long	 1f - 0f
	.long	 4f - 1f
	.long	 5
0:
	.string	 "GNU"
1:
	.align 8
	.long	 0xc0000002
	.long	 3f - 2f
2:
	.long	 0x3
3:
	.align 8
4:
[hjl@gnu-cfl-1 tmp]$
Comment 1 Hans Wennborg 2020-03-23 09:29:08 PDT
Probably not something we can block 10.0.0 for since it's already so late.

Can you comment on the severity of this, i.e. does it fire in real code and why did you only notice now?

Have you tried bisecting this?
Comment 2 H.J. Lu 2020-03-23 09:44:38 PDT
(In reply to Hans Wennborg from comment #1)
> Probably not something we can block 10.0.0 for since it's already so late.
> 
> Can you comment on the severity of this, i.e. does it fire in real code and
> why did you only notice now?

We started LLVM CET testing on CET enabled Linux two weeks ago and noticed
that C++ exception didn't work at all.

> Have you tried bisecting this?

It was fixed by

commit 974d649f8eaf3026ccb9d1b77bdec55da25366e5
Author: Pengfei Wang <pengfei.wang@intel.com>
Date:   Tue Mar 17 21:39:49 2020 -0700

    CET for Exception Handle
    
    Summary:
    Bug fix for https://bugs.llvm.org/show_bug.cgi?id=45182
    Exception handle may indirectly jump to catch pad, So we should add ENDBR instruction before catch pad instructions.
    
    Reviewers: craig.topper, hjl.tools, LuoYuanke, annita.zhang, pengfei
    
    Reviewed By: LuoYuanke
    
    Subscribers: hiraditya, llvm-commits
    
    Patch By: Xiang Zhang (xiangzhangllvm)
    
    Differential Revision: https://reviews.llvm.org/D76190