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
