[all-commits] [llvm/llvm-project] bc044a: [Inline] prevent inlining on stack protector mismatch

[Nick Desaulniers via All-commits]

  Branch: refs/heads/master
  Home:   https://github.com/llvm/llvm-project
  Commit: bc044a88ee3c16e4164740732a7adc91a29b24f5
      https://github.com/llvm/llvm-project/commit/bc044a88ee3c16e4164740732a7adc91a29b24f5
  Author: Nick Desaulniers <ndesaulniers at google.com>
  Date:   2020-12-02 (Wed, 02 Dec 2020)

  Changed paths:
    M llvm/include/llvm/IR/Function.h
    M llvm/lib/Analysis/InlineCost.cpp
    M llvm/lib/CodeGen/StackProtector.cpp
    M llvm/lib/IR/Attributes.cpp
    M llvm/lib/IR/Function.cpp
    M llvm/test/CodeGen/AArch64/stack-guard-remat-bitcast.ll
    M llvm/test/CodeGen/X86/stack-protector-2.ll
    A llvm/test/ThinLTO/X86/nossp.ll
    M llvm/test/Transforms/CodeExtractor/PartialInlineAttributes.ll
    M llvm/test/Transforms/Inline/devirtualize.ll
    M llvm/test/Transforms/Inline/inline-byval-bonus.ll
    A llvm/test/Transforms/Inline/inline_nossp.ll
    M llvm/test/Transforms/Inline/inline_ssp.ll

  Log Message:
  -----------
  [Inline] prevent inlining on stack protector mismatch

It's common for code that manipulates the stack via inline assembly or
that has to set up its own stack canary (such as the Linux kernel) would
like to avoid stack protectors in certain functions. In this case, we've
been bitten by numerous bugs where a callee with a stack protector is
inlined into an attribute((no_stack_protector)) caller, which
generally breaks the caller's assumptions about not having a stack
protector. LTO exacerbates the issue.

While developers can avoid this by putting all no_stack_protector
functions in one translation unit together and compiling those with
-fno-stack-protector, it's generally not very ergonomic or as
ergonomic as a function attribute, and still doesn't work for LTO. See also:
https://lore.kernel.org/linux-pm/20200915172658.1432732-1-rkir@google.com/
https://lore.kernel.org/lkml/20200918201436.2932360-30-samitolvanen@google.com/T/#u

SSP attributes can be ordered by strength. Weakest to strongest, they
are: ssp, sspstrong, sspreq.  Callees with differing SSP attributes may be
inlined into each other, and the strongest attribute will be applied to the
caller. (No change)

After this change:
* A callee with no SSP attributes will no longer be inlined into a
  caller with SSP attributes.
* The reverse is also true: a callee with an SSP attribute will not be
  inlined into a caller with no SSP attributes.
* The alwaysinline attribute overrides these rules.

Functions that get synthesized by the compiler may not get inlined as a
result if they are not created with the same stack protector function
attribute as their callers.

Alternative approach to https://reviews.llvm.org/D87956.

Fixes pr/47479.

Signed-off-by: Nick Desaulniers <ndesaulniers at google.com>

Reviewed By: rnk, MaskRay

Differential Revision: https://reviews.llvm.org/D91816