Add cet.h for writing CET-enabled assembly code

[xiangzhangllvm]

Summary

Add x86 feature with IBT and/or SHSTK bits to ELF program property if they are enabled. Otherwise, contents in this header file are unused.
This file is mainly design for assembly source code which want to enable CET

[hjl.tools]

clang/test/CodeGen/asm-cet.S

2

Please replace -DIBT -DSHSTK with -fcf-protection and also test i386-pc-linux.

[hjl.tools]

clang/lib/Headers/cet.h

18

Please also define _CET_ENDBR. It should be for endbr64/endbr32 when IBT is enabled
and empty when IBT is disabled.

23

Please check CET instead of IBT and SHSTK.

[xiangzhangllvm]

clang/lib/Headers/cet.h

18

Hello, H.J., I not much understand here,
if CET can instead of IBT and SHSTK, why we need extra define _CET_ENDBR ?

23

So here you mean: ?
-fcf-protection --> define macro "CET" 0x3 internally in compiler;
-fcf-protection=ibt --> define macro "CET" 0x1 internally in compiler;
-fcf-protection=shstk --> define macro "CET" 0x2 internally in compiler;

clang/test/CodeGen/asm-cet.S

2

You mean use "-fcf-protection" to define macro "CET" internally in compiler?

[xiangzhangllvm]

clang/lib/Headers/cet.h

18

Oh, I understand it, you want define _CET_ENDBR for endbr64/endbr32, let user to use it when he/she write the assembly code.

[hjl.tools]

clang/lib/Headers/cet.h

18

User can use _CET_ENDBR unconditionally. You should a CET enabled assembly
codes to understand how <cet.h> is used.

23

Yes.

clang/test/CodeGen/asm-cet.S

2

Yes,

6

Add a function label and use _CET_ENDBR. You should check endbr32/endbr64.
You should assemble the same testcase without -fcf-protection. There should be
no endbr32/endbr64 nor CET marker.

[xiangzhangllvm]

Good thing is that: CET is already defined to 1/2/3 according to -fcf-protection=xxx at front end, So we directly used it for preprocessor.

[xiangzhangllvm]

I want to put this patch to llvm10.0.1, could you help review and then accept this patch?

[hjl.tools]

clang/lib/Headers/cet.h

15

Move it after __CET__ block and define it only if it isn't defined.

[LuoYuanke]

clang/test/CodeGen/asm-cet.S

16

This seems not test anything. Maybe test as below code.
NOENDBR-NOT: endbr

[xiangzhangllvm]

clang/lib/Headers/cet.h

15

I think It's better outside of CET block, because user can write the _CET_ENDBR in their assembly code in any case (CET enable or disable).
Or it will fail to compile if user write the _CET_ENDBR in *.S when he/she not use -fcf-protection to enable CET.

clang/test/CodeGen/asm-cet.S

16

Oh! yes, sorry for this mistake.

[hjl.tools]

clang/lib/Headers/cet.h

15

You have

#define _CET_ENDBR
...
#define _CET_ENDBR endbr64

Don't clang complain like

x.c:2:9: warning: '_CET_ENDBR' macro redefined [-Wmacro-redefined]
#define _CET_ENDBR endbr64
        ^
x.c:1:9: note: previous definition is here
#define _CET_ENDBR
        ^
1 warning generated.

[xiangzhangllvm]

clang/lib/Headers/cet.h

15

Yes, I tested it directly use the llvm-lit before, so I miss the warning information.

I add "#ifndef _CET_ENDBR" this time now.

[xiangzhangllvm]

clang/lib/Headers/cet.h

15

I test it, It do not have warning.
But gcc will have warning.

[xiangzhangllvm]

Add #undef _CET_ENDBR

[xiangzhangllvm]

clang/lib/Headers/cet.h

15

I retest it, It really has warning!! Add "#undef xxx" now.

[LuoYuanke]

clang/lib/Headers/cet.h

16

Should we remove line 15? If _CET_ENDBR is defined in another file, we should report warning.

[hjl.tools]

clang/lib/Headers/cet.h

15

I think you should do

#ifdef __CET__
...
#define _CET_ENDBR
...
#endif

#ifndef _CET_ENDBR
#define _CET_ENDBR
#endif

If _CET_ENDBR is defined by programmer, there will be a warnng,

[xiangzhangllvm]

Refine the Macro _CET_ENDBR

[hjl.tools]

In D79617#2028862, @xiangzhangllvm wrote:

Refine the Macro _CET_ENDBR

Works for me.

[xiangzhangllvm]

! In D79617#2029228, @hjl.tools wrote:
Works for me.

Hello, H.J., could you help accept this patch, I hope it can go to llvm 10.0.1.
Thank you!!

[tstellar]

Richard, should review this, since he raised some questions on the bug report.

[xiangzhangllvm]

Hello @rsmith if you feel OK too, could you help accept it. Thank you!
Hello every friends, I plan to commit it in these days, if you do not oppose it, thank you!

[LuoYuanke]

LGTM

[tstellar]

Did @rsmith ever approve this patch? I was following the discussion at llvm.org/PR45484 but did not see an explicit approval.

[xiangzhangllvm]

@rsmith

[rsmith]

I would like a specification for this header to be added somewhere. We shouldn't be implementing random things with no specification. (Suppose someone claims that our <cet.h> is wrong in some way. How would we know whether they're right?)

Ideally, I'd also like this header to be installed somewhere where we look for assembler-with-cpp preprocessing but not for regular compilation; it doesn't make sense to me to pollute the header namespace for all C and C++ compilations with a header that is not meaningful in C and C++. But knowing whether that change is correct depends on having, you know, a specification.

I don't think we should be porting this to Clang 10. It seems clear that this is a new feature, not a bug fix.

[hjl.tools]

In D79617#2045552, @rsmith wrote:

I would like a specification for this header to be added somewhere. We shouldn't be implementing random things with no specification. (Suppose someone claims that our <cet.h> is wrong in some way. How would we know whether they're right?)

Ideally, I'd also like this header to be installed somewhere where we look for assembler-with-cpp preprocessing but not for regular compilation; it doesn't make sense to me to pollute the header namespace for all C and C++ compilations with a header that is not meaningful in C and C++. But knowing whether that change is correct depends on having, you know, a specification.

<cet.h> from GCC is as close as you can get for a reference implementation/specification.

[xiangzhangllvm]

Hello rsmith,
first, very sorry for have committed this patch before your reply, I waited 10 days, I thought you have agreed it.
I think the linux-ABI can be the specification of this head file. The context of this cet.h is according to the linux ABI about CET.
We explained in which case we should use this cet.h file. (line 2-4)
tks

clang/lib/Headers/CMakeLists.txt

set(files
   __clang_cuda_cmath.h
   __clang_cuda_complex_builtins.h
   __clang_cuda_device_functions.h
   __clang_cuda_intrinsics.h
   __clang_cuda_libdevice_declares.h
   __clang_cuda_math_forward_declares.h
   __clang_cuda_runtime_wrapper.h
   cetintrin.h
+  cet.h
   cldemoteintrin.h
   clzerointrin.h
   cpuid.h
   clflushoptintrin.h
   clwbintrin.h
   emmintrin.h
   enqcmdintrin.h
   f16cintrin.h

clang/lib/Headers/cet.h

+/*===------ cet.h -Control-flow Enforcement Technology  feature ------------===
+ * Add x86 feature with IBT and/or SHSTK bits to ELF program property if they
+ * are enabled. Otherwise, contents in this header file are unused. This file
+ * is mainly design for assembly source code which want to enable CET.
+ *
+ * Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
+ * See https://llvm.org/LICENSE.txt for license information.
+ * SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+ *
+ *===-----------------------------------------------------------------------===
+ */
+
+#ifdef __ASSEMBLER__
+
+# define _CET_ENDBR
+
+# ifdef __CET__
+
+#  ifdef __LP64__
+#   define __PROPERTY_ALIGN 3
+#   if __CET__ & 0x1
+#     define _CET_ENDBR endbr64
+#   endif
+#  else
+#   define __PROPERTY_ALIGN 2
+#   if __CET__ & 0x1
+#     define _CET_ENDBR endbr32
+#   endif
+#  endif
+
+  .pushsection ".note.gnu.property", "a"
+  .p2align __PROPERTY_ALIGN
+  .long 1f - 0f   /* name length.  */
+  .long 4f - 1f   /* data length.  */
+  /* NT_GNU_PROPERTY_TYPE_0.   */
+  .long 5     /* note type.  */
+0:
+  .asciz "GNU"    /* vendor name.  */
+1:
+  .p2align __PROPERTY_ALIGN
+  /* GNU_PROPERTY_X86_FEATURE_1_AND.  */
+  .long 0xc0000002  /* pr_type.  */
+  .long 3f - 2f   /* pr_datasz.  */
+2:
+  /* GNU_PROPERTY_X86_FEATURE_1_XXX.  */
+  .long __CET__
+3:
+  .p2align __PROPERTY_ALIGN
+4:
+  .popsection
+# endif
+#endif

clang/test/CodeGen/asm-cet.S

+// RUN: %clang --target=x86_64-pc-linux -fcf-protection  -include cet.h -c %s -o - | llvm-readelf -n | FileCheck %s
+// RUN: %clang --target=x86_64-pc-linux -include cet.h -c %s -o - | llvm-readelf -S | FileCheck %s --check-prefixes=NOCET
+// RUN: %clang --target=x86_64-pc-linux -include cet.h -S %s -o - | FileCheck %s --check-prefixes=NOENDBR
+// RUN: %clang --target=x86_64-pc-linux -fcf-protection  -include cet.h -S %s -o - | FileCheck %s --check-prefixes=ENDBR64
+
+// RUN: %clang --target=i386-pc-linux -fcf-protection  -include cet.h -c %s -o - | llvm-readelf -n | FileCheck %s
+// RUN: %clang --target=i386-pc-linux -include cet.h -c %s -o - | llvm-readelf -S | FileCheck %s --check-prefixes=NOCET
+// RUN: %clang --target=i386-pc-linux -include cet.h -S %s -o - | FileCheck %s --check-prefixes=NOENDBR
+// RUN: %clang --target=i386-pc-linux -fcf-protection  -include cet.h -S %s -o - | FileCheck %s --check-prefixes=ENDBR32
+
+// CHECK: IBT, SHSTK
+
+// NOCET:     Section Headers
+// NOCET-NOT: .note.gnu.property
+
+// NOENDBR:   foo
+// NOCET-NOT: endbr
+
+// ENDBR64: endbr64
+// ENDBR32: endbr32
+        .text
+        .globl  foo
+        .type   foo, @function
+foo:
+        _CET_ENDBR
+        ret