Add Intel Indirect Branch Tracking support.

This allows operating systems to insist on IBT
enforcement as an exploit mitigation mechanism without
needing to make an exception for anything using a
bundled boringssl, such as chrome, mono, and qtwebengine.

Change-Id: Iac28dd3d2af177b89ffde10ae97bce23739feb94
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/60625
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: Bob Beck <bbe@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
diff --git a/include/openssl/asm_base.h b/include/openssl/asm_base.h
index 57a7d4a..f22a1a2 100644
--- a/include/openssl/asm_base.h
+++ b/include/openssl/asm_base.h
@@ -33,6 +33,9 @@
 //
 // - The file, on aarch64, uses the macros defined below to be compatible with
 //   BTI and PAC.
+//
+// - The file, on X86_64, requires the progrram to be compatible with Intel IBT
+//   and SHSTK
 
 #if defined(__ASSEMBLER__)
 
@@ -47,6 +50,22 @@
 .popsection
 #endif
 
+#if defined(__CET__) && defined(OPENSSL_X86_64)
+// Clang and GCC define __CET__ and provide <cet.h> when they support Intel's
+// Indirect Branch Tracking.
+// https://lpc.events/event/7/contributions/729/attachments/496/903/CET-LPC-2020.pdf
+//
+// cet.h defines _CET_ENDBR which is used to mark function entry points for IBT.
+// and adds the assembly marker. The value of _CET_ENDBR is made dependant on if
+// '-fcf-protection' is passed to the compiler. _CET_ENDBR is only required when
+// the function is the target of an indirect jump, but BoringSSL chooses to mark
+// all assembly entry points because it is easier, and allows BoringSSL's ABI
+// tester to call the assembly entry points via an indirect jump.
+#include <cet.h>
+#else
+#define _CET_ENDBR
+#endif
+
 #if defined(OPENSSL_ARM) || defined(OPENSSL_AARCH64)
 
 // We require the ARM assembler provide |__ARM_ARCH| from Arm C Language