2015-12-16 00:00:08 +01:00
|
|
|
//===-- CrossDSOCFI.cpp - Externalize this module's CFI checks ------------===//
|
|
|
|
//
|
2019-01-19 09:50:56 +01:00
|
|
|
// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
|
|
|
|
// See https://llvm.org/LICENSE.txt for license information.
|
|
|
|
// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
|
2015-12-16 00:00:08 +01:00
|
|
|
//
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
//
|
|
|
|
// This pass exports all llvm.bitset's found in the module in the form of a
|
|
|
|
// __cfi_check function, which can be used to verify cross-DSO call targets.
|
|
|
|
//
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
2016-07-09 05:25:35 +02:00
|
|
|
#include "llvm/Transforms/IPO/CrossDSOCFI.h"
|
2017-08-30 06:47:21 +02:00
|
|
|
#include "llvm/ADT/SetVector.h"
|
2015-12-16 00:00:08 +01:00
|
|
|
#include "llvm/ADT/Statistic.h"
|
2017-08-30 00:29:15 +02:00
|
|
|
#include "llvm/ADT/Triple.h"
|
2015-12-16 00:00:08 +01:00
|
|
|
#include "llvm/IR/Constant.h"
|
|
|
|
#include "llvm/IR/Constants.h"
|
|
|
|
#include "llvm/IR/Function.h"
|
|
|
|
#include "llvm/IR/GlobalObject.h"
|
|
|
|
#include "llvm/IR/GlobalVariable.h"
|
|
|
|
#include "llvm/IR/IRBuilder.h"
|
|
|
|
#include "llvm/IR/Instructions.h"
|
|
|
|
#include "llvm/IR/Intrinsics.h"
|
|
|
|
#include "llvm/IR/MDBuilder.h"
|
|
|
|
#include "llvm/IR/Module.h"
|
|
|
|
#include "llvm/IR/Operator.h"
|
Sink all InitializePasses.h includes
This file lists every pass in LLVM, and is included by Pass.h, which is
very popular. Every time we add, remove, or rename a pass in LLVM, it
caused lots of recompilation.
I found this fact by looking at this table, which is sorted by the
number of times a file was changed over the last 100,000 git commits
multiplied by the number of object files that depend on it in the
current checkout:
recompiles touches affected_files header
342380 95 3604 llvm/include/llvm/ADT/STLExtras.h
314730 234 1345 llvm/include/llvm/InitializePasses.h
307036 118 2602 llvm/include/llvm/ADT/APInt.h
213049 59 3611 llvm/include/llvm/Support/MathExtras.h
170422 47 3626 llvm/include/llvm/Support/Compiler.h
162225 45 3605 llvm/include/llvm/ADT/Optional.h
158319 63 2513 llvm/include/llvm/ADT/Triple.h
140322 39 3598 llvm/include/llvm/ADT/StringRef.h
137647 59 2333 llvm/include/llvm/Support/Error.h
131619 73 1803 llvm/include/llvm/Support/FileSystem.h
Before this change, touching InitializePasses.h would cause 1345 files
to recompile. After this change, touching it only causes 550 compiles in
an incremental rebuild.
Reviewers: bkramer, asbirlea, bollu, jdoerfert
Differential Revision: https://reviews.llvm.org/D70211
2019-11-13 22:15:01 +01:00
|
|
|
#include "llvm/InitializePasses.h"
|
2015-12-16 00:00:08 +01:00
|
|
|
#include "llvm/Pass.h"
|
|
|
|
#include "llvm/Support/Debug.h"
|
|
|
|
#include "llvm/Support/raw_ostream.h"
|
2016-07-09 05:25:35 +02:00
|
|
|
#include "llvm/Transforms/IPO.h"
|
2015-12-16 00:00:08 +01:00
|
|
|
|
|
|
|
using namespace llvm;
|
|
|
|
|
|
|
|
#define DEBUG_TYPE "cross-dso-cfi"
|
|
|
|
|
IR: New representation for CFI and virtual call optimization pass metadata.
The bitset metadata currently used in LLVM has a few problems:
1. It has the wrong name. The name "bitset" refers to an implementation
detail of one use of the metadata (i.e. its original use case, CFI).
This makes it harder to understand, as the name makes no sense in the
context of virtual call optimization.
2. It is represented using a global named metadata node, rather than
being directly associated with a global. This makes it harder to
manipulate the metadata when rebuilding global variables, summarise it
as part of ThinLTO and drop unused metadata when associated globals are
dropped. For this reason, CFI does not currently work correctly when
both CFI and vcall opt are enabled, as vcall opt needs to rebuild vtable
globals, and fails to associate metadata with the rebuilt globals. As I
understand it, the same problem could also affect ASan, which rebuilds
globals with a red zone.
This patch solves both of those problems in the following way:
1. Rename the metadata to "type metadata". This new name reflects how
the metadata is currently being used (i.e. to represent type information
for CFI and vtable opt). The new name is reflected in the name for the
associated intrinsic (llvm.type.test) and pass (LowerTypeTests).
2. Attach metadata directly to the globals that it pertains to, rather
than using the "llvm.bitsets" global metadata node as we are doing now.
This is done using the newly introduced capability to attach
metadata to global variables (r271348 and r271358).
See also: http://lists.llvm.org/pipermail/llvm-dev/2016-June/100462.html
Differential Revision: http://reviews.llvm.org/D21053
llvm-svn: 273729
2016-06-24 23:21:32 +02:00
|
|
|
STATISTIC(NumTypeIds, "Number of unique type identifiers");
|
2015-12-16 00:00:08 +01:00
|
|
|
|
|
|
|
namespace {
|
|
|
|
|
|
|
|
struct CrossDSOCFI : public ModulePass {
|
|
|
|
static char ID;
|
|
|
|
CrossDSOCFI() : ModulePass(ID) {
|
|
|
|
initializeCrossDSOCFIPass(*PassRegistry::getPassRegistry());
|
|
|
|
}
|
|
|
|
|
|
|
|
MDNode *VeryLikelyWeights;
|
|
|
|
|
IR: New representation for CFI and virtual call optimization pass metadata.
The bitset metadata currently used in LLVM has a few problems:
1. It has the wrong name. The name "bitset" refers to an implementation
detail of one use of the metadata (i.e. its original use case, CFI).
This makes it harder to understand, as the name makes no sense in the
context of virtual call optimization.
2. It is represented using a global named metadata node, rather than
being directly associated with a global. This makes it harder to
manipulate the metadata when rebuilding global variables, summarise it
as part of ThinLTO and drop unused metadata when associated globals are
dropped. For this reason, CFI does not currently work correctly when
both CFI and vcall opt are enabled, as vcall opt needs to rebuild vtable
globals, and fails to associate metadata with the rebuilt globals. As I
understand it, the same problem could also affect ASan, which rebuilds
globals with a red zone.
This patch solves both of those problems in the following way:
1. Rename the metadata to "type metadata". This new name reflects how
the metadata is currently being used (i.e. to represent type information
for CFI and vtable opt). The new name is reflected in the name for the
associated intrinsic (llvm.type.test) and pass (LowerTypeTests).
2. Attach metadata directly to the globals that it pertains to, rather
than using the "llvm.bitsets" global metadata node as we are doing now.
This is done using the newly introduced capability to attach
metadata to global variables (r271348 and r271358).
See also: http://lists.llvm.org/pipermail/llvm-dev/2016-June/100462.html
Differential Revision: http://reviews.llvm.org/D21053
llvm-svn: 273729
2016-06-24 23:21:32 +02:00
|
|
|
ConstantInt *extractNumericTypeId(MDNode *MD);
|
2016-07-08 21:30:06 +02:00
|
|
|
void buildCFICheck(Module &M);
|
2015-12-16 00:00:08 +01:00
|
|
|
bool runOnModule(Module &M) override;
|
|
|
|
};
|
|
|
|
|
|
|
|
} // anonymous namespace
|
|
|
|
|
|
|
|
INITIALIZE_PASS_BEGIN(CrossDSOCFI, "cross-dso-cfi", "Cross-DSO CFI", false,
|
|
|
|
false)
|
|
|
|
INITIALIZE_PASS_END(CrossDSOCFI, "cross-dso-cfi", "Cross-DSO CFI", false, false)
|
|
|
|
char CrossDSOCFI::ID = 0;
|
|
|
|
|
|
|
|
ModulePass *llvm::createCrossDSOCFIPass() { return new CrossDSOCFI; }
|
|
|
|
|
IR: New representation for CFI and virtual call optimization pass metadata.
The bitset metadata currently used in LLVM has a few problems:
1. It has the wrong name. The name "bitset" refers to an implementation
detail of one use of the metadata (i.e. its original use case, CFI).
This makes it harder to understand, as the name makes no sense in the
context of virtual call optimization.
2. It is represented using a global named metadata node, rather than
being directly associated with a global. This makes it harder to
manipulate the metadata when rebuilding global variables, summarise it
as part of ThinLTO and drop unused metadata when associated globals are
dropped. For this reason, CFI does not currently work correctly when
both CFI and vcall opt are enabled, as vcall opt needs to rebuild vtable
globals, and fails to associate metadata with the rebuilt globals. As I
understand it, the same problem could also affect ASan, which rebuilds
globals with a red zone.
This patch solves both of those problems in the following way:
1. Rename the metadata to "type metadata". This new name reflects how
the metadata is currently being used (i.e. to represent type information
for CFI and vtable opt). The new name is reflected in the name for the
associated intrinsic (llvm.type.test) and pass (LowerTypeTests).
2. Attach metadata directly to the globals that it pertains to, rather
than using the "llvm.bitsets" global metadata node as we are doing now.
This is done using the newly introduced capability to attach
metadata to global variables (r271348 and r271358).
See also: http://lists.llvm.org/pipermail/llvm-dev/2016-June/100462.html
Differential Revision: http://reviews.llvm.org/D21053
llvm-svn: 273729
2016-06-24 23:21:32 +02:00
|
|
|
/// Extracts a numeric type identifier from an MDNode containing type metadata.
|
|
|
|
ConstantInt *CrossDSOCFI::extractNumericTypeId(MDNode *MD) {
|
2015-12-16 00:00:08 +01:00
|
|
|
// This check excludes vtables for classes inside anonymous namespaces.
|
IR: New representation for CFI and virtual call optimization pass metadata.
The bitset metadata currently used in LLVM has a few problems:
1. It has the wrong name. The name "bitset" refers to an implementation
detail of one use of the metadata (i.e. its original use case, CFI).
This makes it harder to understand, as the name makes no sense in the
context of virtual call optimization.
2. It is represented using a global named metadata node, rather than
being directly associated with a global. This makes it harder to
manipulate the metadata when rebuilding global variables, summarise it
as part of ThinLTO and drop unused metadata when associated globals are
dropped. For this reason, CFI does not currently work correctly when
both CFI and vcall opt are enabled, as vcall opt needs to rebuild vtable
globals, and fails to associate metadata with the rebuilt globals. As I
understand it, the same problem could also affect ASan, which rebuilds
globals with a red zone.
This patch solves both of those problems in the following way:
1. Rename the metadata to "type metadata". This new name reflects how
the metadata is currently being used (i.e. to represent type information
for CFI and vtable opt). The new name is reflected in the name for the
associated intrinsic (llvm.type.test) and pass (LowerTypeTests).
2. Attach metadata directly to the globals that it pertains to, rather
than using the "llvm.bitsets" global metadata node as we are doing now.
This is done using the newly introduced capability to attach
metadata to global variables (r271348 and r271358).
See also: http://lists.llvm.org/pipermail/llvm-dev/2016-June/100462.html
Differential Revision: http://reviews.llvm.org/D21053
llvm-svn: 273729
2016-06-24 23:21:32 +02:00
|
|
|
auto TM = dyn_cast<ValueAsMetadata>(MD->getOperand(1));
|
2015-12-16 00:00:08 +01:00
|
|
|
if (!TM)
|
|
|
|
return nullptr;
|
|
|
|
auto C = dyn_cast_or_null<ConstantInt>(TM->getValue());
|
|
|
|
if (!C) return nullptr;
|
|
|
|
// We are looking for i64 constants.
|
|
|
|
if (C->getBitWidth() != 64) return nullptr;
|
|
|
|
|
|
|
|
return C;
|
|
|
|
}
|
|
|
|
|
|
|
|
/// buildCFICheck - emits __cfi_check for the current module.
|
2016-07-08 21:30:06 +02:00
|
|
|
void CrossDSOCFI::buildCFICheck(Module &M) {
|
2015-12-16 00:00:08 +01:00
|
|
|
// FIXME: verify that __cfi_check ends up near the end of the code section,
|
IR: New representation for CFI and virtual call optimization pass metadata.
The bitset metadata currently used in LLVM has a few problems:
1. It has the wrong name. The name "bitset" refers to an implementation
detail of one use of the metadata (i.e. its original use case, CFI).
This makes it harder to understand, as the name makes no sense in the
context of virtual call optimization.
2. It is represented using a global named metadata node, rather than
being directly associated with a global. This makes it harder to
manipulate the metadata when rebuilding global variables, summarise it
as part of ThinLTO and drop unused metadata when associated globals are
dropped. For this reason, CFI does not currently work correctly when
both CFI and vcall opt are enabled, as vcall opt needs to rebuild vtable
globals, and fails to associate metadata with the rebuilt globals. As I
understand it, the same problem could also affect ASan, which rebuilds
globals with a red zone.
This patch solves both of those problems in the following way:
1. Rename the metadata to "type metadata". This new name reflects how
the metadata is currently being used (i.e. to represent type information
for CFI and vtable opt). The new name is reflected in the name for the
associated intrinsic (llvm.type.test) and pass (LowerTypeTests).
2. Attach metadata directly to the globals that it pertains to, rather
than using the "llvm.bitsets" global metadata node as we are doing now.
This is done using the newly introduced capability to attach
metadata to global variables (r271348 and r271358).
See also: http://lists.llvm.org/pipermail/llvm-dev/2016-June/100462.html
Differential Revision: http://reviews.llvm.org/D21053
llvm-svn: 273729
2016-06-24 23:21:32 +02:00
|
|
|
// but before the jump slots created in LowerTypeTests.
|
2017-08-30 06:47:21 +02:00
|
|
|
SetVector<uint64_t> TypeIds;
|
IR: New representation for CFI and virtual call optimization pass metadata.
The bitset metadata currently used in LLVM has a few problems:
1. It has the wrong name. The name "bitset" refers to an implementation
detail of one use of the metadata (i.e. its original use case, CFI).
This makes it harder to understand, as the name makes no sense in the
context of virtual call optimization.
2. It is represented using a global named metadata node, rather than
being directly associated with a global. This makes it harder to
manipulate the metadata when rebuilding global variables, summarise it
as part of ThinLTO and drop unused metadata when associated globals are
dropped. For this reason, CFI does not currently work correctly when
both CFI and vcall opt are enabled, as vcall opt needs to rebuild vtable
globals, and fails to associate metadata with the rebuilt globals. As I
understand it, the same problem could also affect ASan, which rebuilds
globals with a red zone.
This patch solves both of those problems in the following way:
1. Rename the metadata to "type metadata". This new name reflects how
the metadata is currently being used (i.e. to represent type information
for CFI and vtable opt). The new name is reflected in the name for the
associated intrinsic (llvm.type.test) and pass (LowerTypeTests).
2. Attach metadata directly to the globals that it pertains to, rather
than using the "llvm.bitsets" global metadata node as we are doing now.
This is done using the newly introduced capability to attach
metadata to global variables (r271348 and r271358).
See also: http://lists.llvm.org/pipermail/llvm-dev/2016-June/100462.html
Differential Revision: http://reviews.llvm.org/D21053
llvm-svn: 273729
2016-06-24 23:21:32 +02:00
|
|
|
SmallVector<MDNode *, 2> Types;
|
2016-07-08 21:30:06 +02:00
|
|
|
for (GlobalObject &GO : M.global_objects()) {
|
IR: New representation for CFI and virtual call optimization pass metadata.
The bitset metadata currently used in LLVM has a few problems:
1. It has the wrong name. The name "bitset" refers to an implementation
detail of one use of the metadata (i.e. its original use case, CFI).
This makes it harder to understand, as the name makes no sense in the
context of virtual call optimization.
2. It is represented using a global named metadata node, rather than
being directly associated with a global. This makes it harder to
manipulate the metadata when rebuilding global variables, summarise it
as part of ThinLTO and drop unused metadata when associated globals are
dropped. For this reason, CFI does not currently work correctly when
both CFI and vcall opt are enabled, as vcall opt needs to rebuild vtable
globals, and fails to associate metadata with the rebuilt globals. As I
understand it, the same problem could also affect ASan, which rebuilds
globals with a red zone.
This patch solves both of those problems in the following way:
1. Rename the metadata to "type metadata". This new name reflects how
the metadata is currently being used (i.e. to represent type information
for CFI and vtable opt). The new name is reflected in the name for the
associated intrinsic (llvm.type.test) and pass (LowerTypeTests).
2. Attach metadata directly to the globals that it pertains to, rather
than using the "llvm.bitsets" global metadata node as we are doing now.
This is done using the newly introduced capability to attach
metadata to global variables (r271348 and r271358).
See also: http://lists.llvm.org/pipermail/llvm-dev/2016-June/100462.html
Differential Revision: http://reviews.llvm.org/D21053
llvm-svn: 273729
2016-06-24 23:21:32 +02:00
|
|
|
Types.clear();
|
|
|
|
GO.getMetadata(LLVMContext::MD_type, Types);
|
cfi-icall: Allow the jump table to be optionally made non-canonical.
The default behavior of Clang's indirect function call checker will replace
the address of each CFI-checked function in the output file's symbol table
with the address of a jump table entry which will pass CFI checks. We refer
to this as making the jump table `canonical`. This property allows code that
was not compiled with ``-fsanitize=cfi-icall`` to take a CFI-valid address
of a function, but it comes with a couple of caveats that are especially
relevant for users of cross-DSO CFI:
- There is a performance and code size overhead associated with each
exported function, because each such function must have an associated
jump table entry, which must be emitted even in the common case where the
function is never address-taken anywhere in the program, and must be used
even for direct calls between DSOs, in addition to the PLT overhead.
- There is no good way to take a CFI-valid address of a function written in
assembly or a language not supported by Clang. The reason is that the code
generator would need to insert a jump table in order to form a CFI-valid
address for assembly functions, but there is no way in general for the
code generator to determine the language of the function. This may be
possible with LTO in the intra-DSO case, but in the cross-DSO case the only
information available is the function declaration. One possible solution
is to add a C wrapper for each assembly function, but these wrappers can
present a significant maintenance burden for heavy users of assembly in
addition to adding runtime overhead.
For these reasons, we provide the option of making the jump table non-canonical
with the flag ``-fno-sanitize-cfi-canonical-jump-tables``. When the jump
table is made non-canonical, symbol table entries point directly to the
function body. Any instances of a function's address being taken in C will
be replaced with a jump table address.
This scheme does have its own caveats, however. It does end up breaking
function address equality more aggressively than the default behavior,
especially in cross-DSO mode which normally preserves function address
equality entirely.
Furthermore, it is occasionally necessary for code not compiled with
``-fsanitize=cfi-icall`` to take a function address that is valid
for CFI. For example, this is necessary when a function's address
is taken by assembly code and then called by CFI-checking C code. The
``__attribute__((cfi_jump_table_canonical))`` attribute may be used to make
the jump table entry of a specific function canonical so that the external
code will end up taking a address for the function that will pass CFI checks.
Fixes PR41972.
Differential Revision: https://reviews.llvm.org/D65629
llvm-svn: 368495
2019-08-10 00:31:59 +02:00
|
|
|
for (MDNode *Type : Types)
|
IR: New representation for CFI and virtual call optimization pass metadata.
The bitset metadata currently used in LLVM has a few problems:
1. It has the wrong name. The name "bitset" refers to an implementation
detail of one use of the metadata (i.e. its original use case, CFI).
This makes it harder to understand, as the name makes no sense in the
context of virtual call optimization.
2. It is represented using a global named metadata node, rather than
being directly associated with a global. This makes it harder to
manipulate the metadata when rebuilding global variables, summarise it
as part of ThinLTO and drop unused metadata when associated globals are
dropped. For this reason, CFI does not currently work correctly when
both CFI and vcall opt are enabled, as vcall opt needs to rebuild vtable
globals, and fails to associate metadata with the rebuilt globals. As I
understand it, the same problem could also affect ASan, which rebuilds
globals with a red zone.
This patch solves both of those problems in the following way:
1. Rename the metadata to "type metadata". This new name reflects how
the metadata is currently being used (i.e. to represent type information
for CFI and vtable opt). The new name is reflected in the name for the
associated intrinsic (llvm.type.test) and pass (LowerTypeTests).
2. Attach metadata directly to the globals that it pertains to, rather
than using the "llvm.bitsets" global metadata node as we are doing now.
This is done using the newly introduced capability to attach
metadata to global variables (r271348 and r271358).
See also: http://lists.llvm.org/pipermail/llvm-dev/2016-June/100462.html
Differential Revision: http://reviews.llvm.org/D21053
llvm-svn: 273729
2016-06-24 23:21:32 +02:00
|
|
|
if (ConstantInt *TypeId = extractNumericTypeId(Type))
|
|
|
|
TypeIds.insert(TypeId->getZExtValue());
|
|
|
|
}
|
2015-12-16 00:00:08 +01:00
|
|
|
|
2017-06-16 02:18:29 +02:00
|
|
|
NamedMDNode *CfiFunctionsMD = M.getNamedMetadata("cfi.functions");
|
|
|
|
if (CfiFunctionsMD) {
|
|
|
|
for (auto Func : CfiFunctionsMD->operands()) {
|
|
|
|
assert(Func->getNumOperands() >= 2);
|
|
|
|
for (unsigned I = 2; I < Func->getNumOperands(); ++I)
|
|
|
|
if (ConstantInt *TypeId =
|
|
|
|
extractNumericTypeId(cast<MDNode>(Func->getOperand(I).get())))
|
|
|
|
TypeIds.insert(TypeId->getZExtValue());
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2016-07-08 21:30:06 +02:00
|
|
|
LLVMContext &Ctx = M.getContext();
|
[opaque pointer types] Add a FunctionCallee wrapper type, and use it.
Recommit r352791 after tweaking DerivedTypes.h slightly, so that gcc
doesn't choke on it, hopefully.
Original Message:
The FunctionCallee type is effectively a {FunctionType*,Value*} pair,
and is a useful convenience to enable code to continue passing the
result of getOrInsertFunction() through to EmitCall, even once pointer
types lose their pointee-type.
Then:
- update the CallInst/InvokeInst instruction creation functions to
take a Callee,
- modify getOrInsertFunction to return FunctionCallee, and
- update all callers appropriately.
One area of particular note is the change to the sanitizer
code. Previously, they had been casting the result of
`getOrInsertFunction` to a `Function*` via
`checkSanitizerInterfaceFunction`, and storing that. That would report
an error if someone had already inserted a function declaraction with
a mismatching signature.
However, in general, LLVM allows for such mismatches, as
`getOrInsertFunction` will automatically insert a bitcast if
needed. As part of this cleanup, cause the sanitizer code to do the
same. (It will call its functions using the expected signature,
however they may have been declared.)
Finally, in a small number of locations, callers of
`getOrInsertFunction` actually were expecting/requiring that a brand
new function was being created. In such cases, I've switched them to
Function::Create instead.
Differential Revision: https://reviews.llvm.org/D57315
llvm-svn: 352827
2019-02-01 03:28:03 +01:00
|
|
|
FunctionCallee C = M.getOrInsertFunction(
|
2016-01-26 00:35:03 +01:00
|
|
|
"__cfi_check", Type::getVoidTy(Ctx), Type::getInt64Ty(Ctx),
|
2017-04-11 17:01:18 +02:00
|
|
|
Type::getInt8PtrTy(Ctx), Type::getInt8PtrTy(Ctx));
|
2019-10-21 19:15:25 +02:00
|
|
|
Function *F = cast<Function>(C.getCallee());
|
2017-04-08 01:00:20 +02:00
|
|
|
// Take over the existing function. The frontend emits a weak stub so that the
|
|
|
|
// linker knows about the symbol; this pass replaces the function body.
|
|
|
|
F->deleteBody();
|
2019-10-15 13:24:36 +02:00
|
|
|
F->setAlignment(Align(4096));
|
2017-08-30 00:29:15 +02:00
|
|
|
|
|
|
|
Triple T(M.getTargetTriple());
|
|
|
|
if (T.isARM() || T.isThumb())
|
|
|
|
F->addFnAttr("target-features", "+thumb-mode");
|
|
|
|
|
2015-12-16 00:00:08 +01:00
|
|
|
auto args = F->arg_begin();
|
2016-01-26 00:35:03 +01:00
|
|
|
Value &CallSiteTypeId = *(args++);
|
2015-12-16 00:00:08 +01:00
|
|
|
CallSiteTypeId.setName("CallSiteTypeId");
|
2016-01-26 00:35:03 +01:00
|
|
|
Value &Addr = *(args++);
|
2015-12-16 00:00:08 +01:00
|
|
|
Addr.setName("Addr");
|
2016-01-26 00:35:03 +01:00
|
|
|
Value &CFICheckFailData = *(args++);
|
|
|
|
CFICheckFailData.setName("CFICheckFailData");
|
2015-12-16 00:00:08 +01:00
|
|
|
assert(args == F->arg_end());
|
|
|
|
|
|
|
|
BasicBlock *BB = BasicBlock::Create(Ctx, "entry", F);
|
2016-01-26 00:35:03 +01:00
|
|
|
BasicBlock *ExitBB = BasicBlock::Create(Ctx, "exit", F);
|
2015-12-16 00:00:08 +01:00
|
|
|
|
2016-01-26 00:35:03 +01:00
|
|
|
BasicBlock *TrapBB = BasicBlock::Create(Ctx, "fail", F);
|
|
|
|
IRBuilder<> IRBFail(TrapBB);
|
[opaque pointer types] Add a FunctionCallee wrapper type, and use it.
Recommit r352791 after tweaking DerivedTypes.h slightly, so that gcc
doesn't choke on it, hopefully.
Original Message:
The FunctionCallee type is effectively a {FunctionType*,Value*} pair,
and is a useful convenience to enable code to continue passing the
result of getOrInsertFunction() through to EmitCall, even once pointer
types lose their pointee-type.
Then:
- update the CallInst/InvokeInst instruction creation functions to
take a Callee,
- modify getOrInsertFunction to return FunctionCallee, and
- update all callers appropriately.
One area of particular note is the change to the sanitizer
code. Previously, they had been casting the result of
`getOrInsertFunction` to a `Function*` via
`checkSanitizerInterfaceFunction`, and storing that. That would report
an error if someone had already inserted a function declaraction with
a mismatching signature.
However, in general, LLVM allows for such mismatches, as
`getOrInsertFunction` will automatically insert a bitcast if
needed. As part of this cleanup, cause the sanitizer code to do the
same. (It will call its functions using the expected signature,
however they may have been declared.)
Finally, in a small number of locations, callers of
`getOrInsertFunction` actually were expecting/requiring that a brand
new function was being created. In such cases, I've switched them to
Function::Create instead.
Differential Revision: https://reviews.llvm.org/D57315
llvm-svn: 352827
2019-02-01 03:28:03 +01:00
|
|
|
FunctionCallee CFICheckFailFn =
|
|
|
|
M.getOrInsertFunction("__cfi_check_fail", Type::getVoidTy(Ctx),
|
|
|
|
Type::getInt8PtrTy(Ctx), Type::getInt8PtrTy(Ctx));
|
2016-01-26 00:35:03 +01:00
|
|
|
IRBFail.CreateCall(CFICheckFailFn, {&CFICheckFailData, &Addr});
|
|
|
|
IRBFail.CreateBr(ExitBB);
|
2015-12-16 00:00:08 +01:00
|
|
|
|
|
|
|
IRBuilder<> IRBExit(ExitBB);
|
|
|
|
IRBExit.CreateRetVoid();
|
|
|
|
|
|
|
|
IRBuilder<> IRB(BB);
|
IR: New representation for CFI and virtual call optimization pass metadata.
The bitset metadata currently used in LLVM has a few problems:
1. It has the wrong name. The name "bitset" refers to an implementation
detail of one use of the metadata (i.e. its original use case, CFI).
This makes it harder to understand, as the name makes no sense in the
context of virtual call optimization.
2. It is represented using a global named metadata node, rather than
being directly associated with a global. This makes it harder to
manipulate the metadata when rebuilding global variables, summarise it
as part of ThinLTO and drop unused metadata when associated globals are
dropped. For this reason, CFI does not currently work correctly when
both CFI and vcall opt are enabled, as vcall opt needs to rebuild vtable
globals, and fails to associate metadata with the rebuilt globals. As I
understand it, the same problem could also affect ASan, which rebuilds
globals with a red zone.
This patch solves both of those problems in the following way:
1. Rename the metadata to "type metadata". This new name reflects how
the metadata is currently being used (i.e. to represent type information
for CFI and vtable opt). The new name is reflected in the name for the
associated intrinsic (llvm.type.test) and pass (LowerTypeTests).
2. Attach metadata directly to the globals that it pertains to, rather
than using the "llvm.bitsets" global metadata node as we are doing now.
This is done using the newly introduced capability to attach
metadata to global variables (r271348 and r271358).
See also: http://lists.llvm.org/pipermail/llvm-dev/2016-June/100462.html
Differential Revision: http://reviews.llvm.org/D21053
llvm-svn: 273729
2016-06-24 23:21:32 +02:00
|
|
|
SwitchInst *SI = IRB.CreateSwitch(&CallSiteTypeId, TrapBB, TypeIds.size());
|
|
|
|
for (uint64_t TypeId : TypeIds) {
|
2015-12-16 00:00:08 +01:00
|
|
|
ConstantInt *CaseTypeId = ConstantInt::get(Type::getInt64Ty(Ctx), TypeId);
|
|
|
|
BasicBlock *TestBB = BasicBlock::Create(Ctx, "test", F);
|
|
|
|
IRBuilder<> IRBTest(TestBB);
|
2016-07-08 21:30:06 +02:00
|
|
|
Function *BitsetTestFn = Intrinsic::getDeclaration(&M, Intrinsic::type_test);
|
2015-12-16 00:00:08 +01:00
|
|
|
|
|
|
|
Value *Test = IRBTest.CreateCall(
|
|
|
|
BitsetTestFn, {&Addr, MetadataAsValue::get(
|
|
|
|
Ctx, ConstantAsMetadata::get(CaseTypeId))});
|
|
|
|
BranchInst *BI = IRBTest.CreateCondBr(Test, ExitBB, TrapBB);
|
|
|
|
BI->setMetadata(LLVMContext::MD_prof, VeryLikelyWeights);
|
|
|
|
|
|
|
|
SI->addCase(CaseTypeId, TestBB);
|
IR: New representation for CFI and virtual call optimization pass metadata.
The bitset metadata currently used in LLVM has a few problems:
1. It has the wrong name. The name "bitset" refers to an implementation
detail of one use of the metadata (i.e. its original use case, CFI).
This makes it harder to understand, as the name makes no sense in the
context of virtual call optimization.
2. It is represented using a global named metadata node, rather than
being directly associated with a global. This makes it harder to
manipulate the metadata when rebuilding global variables, summarise it
as part of ThinLTO and drop unused metadata when associated globals are
dropped. For this reason, CFI does not currently work correctly when
both CFI and vcall opt are enabled, as vcall opt needs to rebuild vtable
globals, and fails to associate metadata with the rebuilt globals. As I
understand it, the same problem could also affect ASan, which rebuilds
globals with a red zone.
This patch solves both of those problems in the following way:
1. Rename the metadata to "type metadata". This new name reflects how
the metadata is currently being used (i.e. to represent type information
for CFI and vtable opt). The new name is reflected in the name for the
associated intrinsic (llvm.type.test) and pass (LowerTypeTests).
2. Attach metadata directly to the globals that it pertains to, rather
than using the "llvm.bitsets" global metadata node as we are doing now.
This is done using the newly introduced capability to attach
metadata to global variables (r271348 and r271358).
See also: http://lists.llvm.org/pipermail/llvm-dev/2016-June/100462.html
Differential Revision: http://reviews.llvm.org/D21053
llvm-svn: 273729
2016-06-24 23:21:32 +02:00
|
|
|
++NumTypeIds;
|
2015-12-16 00:00:08 +01:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
bool CrossDSOCFI::runOnModule(Module &M) {
|
2016-07-08 21:30:06 +02:00
|
|
|
VeryLikelyWeights =
|
|
|
|
MDBuilder(M.getContext()).createBranchWeights((1U << 20) - 1, 1);
|
2015-12-16 00:00:08 +01:00
|
|
|
if (M.getModuleFlag("Cross-DSO CFI") == nullptr)
|
|
|
|
return false;
|
2016-07-08 21:30:06 +02:00
|
|
|
buildCFICheck(M);
|
2015-12-16 00:00:08 +01:00
|
|
|
return true;
|
|
|
|
}
|
2016-07-09 05:25:35 +02:00
|
|
|
|
2016-08-09 02:28:38 +02:00
|
|
|
PreservedAnalyses CrossDSOCFIPass::run(Module &M, ModuleAnalysisManager &AM) {
|
2016-07-09 05:25:35 +02:00
|
|
|
CrossDSOCFI Impl;
|
|
|
|
bool Changed = Impl.runOnModule(M);
|
|
|
|
if (!Changed)
|
|
|
|
return PreservedAnalyses::all();
|
|
|
|
return PreservedAnalyses::none();
|
|
|
|
}
|