aboutsummaryrefslogtreecommitdiff
path: root/llvm/lib/Transforms/Utils/InlineFunction.cpp
diff options
context:
space:
mode:
authorNick Desaulniers <ndesaulniers@google.com>2020-10-23 11:41:17 -0700
committerNick Desaulniers <ndesaulniers@google.com>2020-10-23 11:55:39 -0700
commitb7926ce6d7a83cdf70c68d82bc3389c04009b841 (patch)
tree8d599424ac6e96477709b8e3f5afdc945969ddd2 /llvm/lib/Transforms/Utils/InlineFunction.cpp
parenta4459feca415a757fa0ca3ab4731a17240931a81 (diff)
downloadllvm-b7926ce6d7a83cdf70c68d82bc3389c04009b841.zip
llvm-b7926ce6d7a83cdf70c68d82bc3389c04009b841.tar.gz
llvm-b7926ce6d7a83cdf70c68d82bc3389c04009b841.tar.bz2
[IR] add fn attr for no_stack_protector; prevent inlining on mismatch
It's currently ambiguous in IR whether the source language explicitly did not want a stack a stack protector (in C, via function attribute no_stack_protector) or doesn't care for any given function. 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 Typically, when inlining a callee into a caller, the caller will be upgraded in its level of stack protection (see adjustCallerSSPLevel()). By adding an explicit attribute in the IR when the function attribute is used in the source language, we can now identify such cases and prevent inlining. Block inlining when the callee and caller differ in the case that one contains `nossp` when the other has `ssp`, `sspstrong`, or `sspreq`. Fixes pr/47479. Reviewed By: void Differential Revision: https://reviews.llvm.org/D87956
Diffstat (limited to 'llvm/lib/Transforms/Utils/InlineFunction.cpp')
-rw-r--r--llvm/lib/Transforms/Utils/InlineFunction.cpp16
1 files changed, 16 insertions, 0 deletions
diff --git a/llvm/lib/Transforms/Utils/InlineFunction.cpp b/llvm/lib/Transforms/Utils/InlineFunction.cpp
index 7ff21d7..340fe61 100644
--- a/llvm/lib/Transforms/Utils/InlineFunction.cpp
+++ b/llvm/lib/Transforms/Utils/InlineFunction.cpp
@@ -1676,6 +1676,22 @@ llvm::InlineResult llvm::InlineFunction(CallBase &CB, InlineFunctionInfo &IFI,
return InlineResult::failure("incompatible GC");
}
+ // Inlining a function that explicitly should not have a stack protector may
+ // break the code if inlined into a function that does have a stack
+ // protector.
+ if (LLVM_UNLIKELY(Caller->hasFnAttribute(Attribute::NoStackProtect)))
+ if (CalledFunc->hasFnAttribute(Attribute::StackProtect) ||
+ CalledFunc->hasFnAttribute(Attribute::StackProtectStrong) ||
+ CalledFunc->hasFnAttribute(Attribute::StackProtectReq))
+ return InlineResult::failure(
+ "stack protected callee but caller requested no stack protector");
+ if (LLVM_UNLIKELY(CalledFunc->hasFnAttribute(Attribute::NoStackProtect)))
+ if (Caller->hasFnAttribute(Attribute::StackProtect) ||
+ Caller->hasFnAttribute(Attribute::StackProtectStrong) ||
+ Caller->hasFnAttribute(Attribute::StackProtectReq))
+ return InlineResult::failure(
+ "stack protected caller but callee requested no stack protector");
+
// Get the personality function from the callee if it contains a landing pad.
Constant *CalledPersonality =
CalledFunc->hasPersonalityFn()