[PATCH] D118052: [X86] Fix CodeGen Module Flag for -mibt-seal

Tue Apr 5 15:02:29 PDT 2022

joaomoreira added inline comments.

================
Comment at: clang/test/CodeGen/X86/x86-cf-protection.c:4
 // RUN: %clang -target i386-unknown-unknown -x c -E -dM -o - -fcf-protection=full %s   | FileCheck %s --check-prefix=FULL
+// RUN: %clang -target i386-unknown-unknown -o - -emit-llvm -S -fcf-protection=branch -mibt-seal -flto %s | FileCheck %s --check-prefix=IBTSEAL

----------------
xiangzhangllvm wrote:
> joaomoreira wrote:
> > pengfei wrote:
> > > Is `-flto` is required?
> > Yes, we can only suppress ENDBR if we are sure the given function is not address taken in all other translation units.
> Sorry, let me make sure here. what is the "translation units" here mean? Does it means another binary file (e.g. *.so , *.a)?
> Using -flto seems here want more compile units (source files) to be one "translation units"?
Translation unit means a source file translated into an object file. When compiling the kernel, we have different .c files that are translated into different .o files. Each .c translated into .o is a translation unit. Because a function might not be address taken in the translation unit where it is defined but could be address taken in a different one, we need to emit ENDBRs to all non-local (static) functions. With LTO this changes, because we can look at all to-be-generated objects and be sure that a given function is not address taken in any of the translation units.

This optimization is kernel-specific because in user-space code non-local functions can be reached through the PLT of a different dynamically linked library (.so) or through dlsym, and this is impossible to predict in compilation time.

In kernel, exported symbols are implicitly address taken. This way, if a module tries to take the address of an exported function, this would be ok. The optimization will mostly rule-out non-static functions that are not exported from receiving an ENDBR. The numeric benefits of the optimization are shown in https://reviews.llvm.org/D116070

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D118052/new/

https://reviews.llvm.org/D118052