2018-01-09 16:51:18 +08:00
|
|
|
//===---- X86IndirectBranchTracking.cpp - Enables CET IBT mechanism -------===//
|
|
|
|
//
|
2019-01-19 16:50:56 +08: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
|
2018-01-09 16:51:18 +08:00
|
|
|
//
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
//
|
|
|
|
// This file defines a pass that enables Indirect Branch Tracking (IBT) as part
|
|
|
|
// of Control-Flow Enforcement Technology (CET).
|
|
|
|
// The pass adds ENDBR (End Branch) machine instructions at the beginning of
|
|
|
|
// each basic block or function that is referenced by an indrect jump/call
|
|
|
|
// instruction.
|
|
|
|
// The ENDBR instructions have a NOP encoding and as such are ignored in
|
|
|
|
// targets that do not support CET IBT mechanism.
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
|
|
|
#include "X86.h"
|
|
|
|
#include "X86InstrInfo.h"
|
|
|
|
#include "X86Subtarget.h"
|
Enable IBT(Indirect Branch Tracking) in JIT with CET(Control-flow Enforcement Technology)
Do not commit the llvm/test/ExecutionEngine/MCJIT/cet-code-model-lager.ll because it will
cause build bot fail(not suitable for window 32 target).
Summary:
This patch comes from H.J.'s https://github.com/hjl-tools/llvm-project/commit/2bd54ce7fa9e94fcd1118b948e14d1b6fc54dfd2
**This patch fix the failed llvm unit tests which running on CET machine. **(e.g. ExecutionEngine/MCJIT/MCJITTests)
The reason we enable IBT at "JIT compiled with CET" is mainly that: the JIT don't know the its caller program is CET enable or not.
If JIT's caller program is non-CET, it is no problem JIT generate CET code or not.
But if JIT's caller program is CET enabled, JIT must generate CET code or it will cause Control protection exceptions.
I have test the patch at llvm-unit-test and llvm-test-suite at CET machine. It passed.
and H.J. also test it at building and running VNCserver(Virtual Network Console), it works too.
(if not apply this patch, VNCserver will crash at CET machine.)
Reviewers: hjl.tools, craig.topper, LuoYuanke, annita.zhang, pengfei
Reviewed By: LuoYuanke
Subscribers: tstellar, efriedma, hiraditya, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D76900
2020-04-07 08:59:13 +08:00
|
|
|
#include "X86TargetMachine.h"
|
2018-01-09 16:51:18 +08:00
|
|
|
#include "llvm/ADT/Statistic.h"
|
|
|
|
#include "llvm/CodeGen/MachineFunctionPass.h"
|
|
|
|
#include "llvm/CodeGen/MachineInstrBuilder.h"
|
|
|
|
#include "llvm/CodeGen/MachineModuleInfo.h"
|
|
|
|
|
|
|
|
using namespace llvm;
|
|
|
|
|
|
|
|
#define DEBUG_TYPE "x86-indirect-branch-tracking"
|
|
|
|
|
2020-10-27 15:20:03 +08:00
|
|
|
cl::opt<bool> IndirectBranchTracking(
|
2018-01-09 16:51:18 +08:00
|
|
|
"x86-indirect-branch-tracking", cl::init(false), cl::Hidden,
|
|
|
|
cl::desc("Enable X86 indirect branch tracking pass."));
|
|
|
|
|
|
|
|
STATISTIC(NumEndBranchAdded, "Number of ENDBR instructions added");
|
|
|
|
|
|
|
|
namespace {
|
|
|
|
class X86IndirectBranchTrackingPass : public MachineFunctionPass {
|
|
|
|
public:
|
|
|
|
X86IndirectBranchTrackingPass() : MachineFunctionPass(ID) {}
|
|
|
|
|
|
|
|
StringRef getPassName() const override {
|
|
|
|
return "X86 Indirect Branch Tracking";
|
|
|
|
}
|
|
|
|
|
|
|
|
bool runOnMachineFunction(MachineFunction &MF) override;
|
|
|
|
|
|
|
|
private:
|
|
|
|
static char ID;
|
|
|
|
|
|
|
|
/// Machine instruction info used throughout the class.
|
2019-11-05 01:24:18 +08:00
|
|
|
const X86InstrInfo *TII = nullptr;
|
2018-01-09 16:51:18 +08:00
|
|
|
|
|
|
|
/// Endbr opcode for the current machine function.
|
2019-11-05 01:24:18 +08:00
|
|
|
unsigned int EndbrOpcode = 0;
|
2018-01-09 16:51:18 +08:00
|
|
|
|
2019-10-29 20:32:01 +08:00
|
|
|
/// Adds a new ENDBR instruction to the beginning of the MBB.
|
2018-01-09 16:51:18 +08:00
|
|
|
/// The function will not add it if already exists.
|
|
|
|
/// It will add ENDBR32 or ENDBR64 opcode, depending on the target.
|
2018-03-17 21:29:46 +08:00
|
|
|
/// \returns true if the ENDBR was added and false otherwise.
|
2019-05-22 08:50:21 +08:00
|
|
|
bool addENDBR(MachineBasicBlock &MBB, MachineBasicBlock::iterator I) const;
|
2018-01-09 16:51:18 +08:00
|
|
|
};
|
|
|
|
|
|
|
|
} // end anonymous namespace
|
|
|
|
|
|
|
|
char X86IndirectBranchTrackingPass::ID = 0;
|
|
|
|
|
|
|
|
FunctionPass *llvm::createX86IndirectBranchTrackingPass() {
|
|
|
|
return new X86IndirectBranchTrackingPass();
|
|
|
|
}
|
|
|
|
|
2019-05-22 08:50:21 +08:00
|
|
|
bool X86IndirectBranchTrackingPass::addENDBR(
|
|
|
|
MachineBasicBlock &MBB, MachineBasicBlock::iterator I) const {
|
2018-01-09 16:51:18 +08:00
|
|
|
assert(TII && "Target instruction info was not initialized");
|
|
|
|
assert((X86::ENDBR64 == EndbrOpcode || X86::ENDBR32 == EndbrOpcode) &&
|
|
|
|
"Unexpected Endbr opcode");
|
|
|
|
|
2019-05-22 08:50:21 +08:00
|
|
|
// If the MBB/I is empty or the current instruction is not ENDBR,
|
|
|
|
// insert ENDBR instruction to the location of I.
|
|
|
|
if (I == MBB.end() || I->getOpcode() != EndbrOpcode) {
|
|
|
|
BuildMI(MBB, I, MBB.findDebugLoc(I), TII->get(EndbrOpcode));
|
|
|
|
++NumEndBranchAdded;
|
2018-03-17 21:29:46 +08:00
|
|
|
return true;
|
2018-01-09 16:51:18 +08:00
|
|
|
}
|
2019-05-22 08:50:21 +08:00
|
|
|
return false;
|
|
|
|
}
|
2018-03-17 21:29:46 +08:00
|
|
|
|
2019-08-24 03:59:23 +08:00
|
|
|
static bool IsCallReturnTwice(llvm::MachineOperand &MOp) {
|
2019-05-22 08:50:21 +08:00
|
|
|
if (!MOp.isGlobal())
|
|
|
|
return false;
|
|
|
|
auto *CalleeFn = dyn_cast<Function>(MOp.getGlobal());
|
|
|
|
if (!CalleeFn)
|
|
|
|
return false;
|
|
|
|
AttributeList Attrs = CalleeFn->getAttributes();
|
2020-06-15 05:52:39 +08:00
|
|
|
return Attrs.hasFnAttribute(Attribute::ReturnsTwice);
|
2018-01-09 16:51:18 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
bool X86IndirectBranchTrackingPass::runOnMachineFunction(MachineFunction &MF) {
|
|
|
|
const X86Subtarget &SubTarget = MF.getSubtarget<X86Subtarget>();
|
|
|
|
|
|
|
|
// Check that the cf-protection-branch is enabled.
|
|
|
|
Metadata *isCFProtectionSupported =
|
|
|
|
MF.getMMI().getModule()->getModuleFlag("cf-protection-branch");
|
Enable IBT(Indirect Branch Tracking) in JIT with CET(Control-flow Enforcement Technology)
Do not commit the llvm/test/ExecutionEngine/MCJIT/cet-code-model-lager.ll because it will
cause build bot fail(not suitable for window 32 target).
Summary:
This patch comes from H.J.'s https://github.com/hjl-tools/llvm-project/commit/2bd54ce7fa9e94fcd1118b948e14d1b6fc54dfd2
**This patch fix the failed llvm unit tests which running on CET machine. **(e.g. ExecutionEngine/MCJIT/MCJITTests)
The reason we enable IBT at "JIT compiled with CET" is mainly that: the JIT don't know the its caller program is CET enable or not.
If JIT's caller program is non-CET, it is no problem JIT generate CET code or not.
But if JIT's caller program is CET enabled, JIT must generate CET code or it will cause Control protection exceptions.
I have test the patch at llvm-unit-test and llvm-test-suite at CET machine. It passed.
and H.J. also test it at building and running VNCserver(Virtual Network Console), it works too.
(if not apply this patch, VNCserver will crash at CET machine.)
Reviewers: hjl.tools, craig.topper, LuoYuanke, annita.zhang, pengfei
Reviewed By: LuoYuanke
Subscribers: tstellar, efriedma, hiraditya, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D76900
2020-04-07 08:59:13 +08:00
|
|
|
// NB: We need to enable IBT in jitted code if JIT compiler is CET
|
|
|
|
// enabled.
|
|
|
|
const X86TargetMachine *TM =
|
|
|
|
static_cast<const X86TargetMachine *>(&MF.getTarget());
|
|
|
|
#ifdef __CET__
|
|
|
|
bool isJITwithCET = TM->isJIT();
|
|
|
|
#else
|
|
|
|
bool isJITwithCET = false;
|
|
|
|
#endif
|
|
|
|
if (!isCFProtectionSupported && !IndirectBranchTracking && !isJITwithCET)
|
2018-01-09 16:51:18 +08:00
|
|
|
return false;
|
|
|
|
|
|
|
|
// True if the current MF was changed and false otherwise.
|
|
|
|
bool Changed = false;
|
|
|
|
|
|
|
|
TII = SubTarget.getInstrInfo();
|
|
|
|
EndbrOpcode = SubTarget.is64Bit() ? X86::ENDBR64 : X86::ENDBR32;
|
|
|
|
|
Enable IBT(Indirect Branch Tracking) in JIT with CET(Control-flow Enforcement Technology)
Do not commit the llvm/test/ExecutionEngine/MCJIT/cet-code-model-lager.ll because it will
cause build bot fail(not suitable for window 32 target).
Summary:
This patch comes from H.J.'s https://github.com/hjl-tools/llvm-project/commit/2bd54ce7fa9e94fcd1118b948e14d1b6fc54dfd2
**This patch fix the failed llvm unit tests which running on CET machine. **(e.g. ExecutionEngine/MCJIT/MCJITTests)
The reason we enable IBT at "JIT compiled with CET" is mainly that: the JIT don't know the its caller program is CET enable or not.
If JIT's caller program is non-CET, it is no problem JIT generate CET code or not.
But if JIT's caller program is CET enabled, JIT must generate CET code or it will cause Control protection exceptions.
I have test the patch at llvm-unit-test and llvm-test-suite at CET machine. It passed.
and H.J. also test it at building and running VNCserver(Virtual Network Console), it works too.
(if not apply this patch, VNCserver will crash at CET machine.)
Reviewers: hjl.tools, craig.topper, LuoYuanke, annita.zhang, pengfei
Reviewed By: LuoYuanke
Subscribers: tstellar, efriedma, hiraditya, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D76900
2020-04-07 08:59:13 +08:00
|
|
|
// Large code model, non-internal function or function whose address
|
|
|
|
// was taken, can be accessed through indirect calls. Mark the first
|
|
|
|
// BB with ENDBR instruction unless nocf_check attribute is used.
|
|
|
|
if ((TM->getCodeModel() == CodeModel::Large ||
|
|
|
|
MF.getFunction().hasAddressTaken() ||
|
2018-03-17 21:29:46 +08:00
|
|
|
!MF.getFunction().hasLocalLinkage()) &&
|
|
|
|
!MF.getFunction().doesNoCfCheck()) {
|
2018-01-09 16:51:18 +08:00
|
|
|
auto MBB = MF.begin();
|
2019-05-22 08:50:21 +08:00
|
|
|
Changed |= addENDBR(*MBB, MBB->begin());
|
2018-01-09 16:51:18 +08:00
|
|
|
}
|
|
|
|
|
2019-05-22 08:50:21 +08:00
|
|
|
for (auto &MBB : MF) {
|
2018-03-17 21:29:46 +08:00
|
|
|
// Find all basic blocks that their address was taken (for example
|
2018-01-09 16:51:18 +08:00
|
|
|
// in the case of indirect jump) and add ENDBR instruction.
|
2018-03-17 21:29:46 +08:00
|
|
|
if (MBB.hasAddressTaken())
|
2019-05-22 08:50:21 +08:00
|
|
|
Changed |= addENDBR(MBB, MBB.begin());
|
|
|
|
|
|
|
|
for (MachineBasicBlock::iterator I = MBB.begin(); I != MBB.end(); ++I) {
|
2020-03-18 12:39:49 +08:00
|
|
|
if (I->isCall() && IsCallReturnTwice(I->getOperand(0)))
|
2019-05-22 08:50:21 +08:00
|
|
|
Changed |= addENDBR(MBB, std::next(I));
|
2020-04-20 10:17:34 +08:00
|
|
|
}
|
2020-03-18 12:39:49 +08:00
|
|
|
|
2020-04-20 10:17:34 +08:00
|
|
|
// Exception handle may indirectly jump to catch pad, So we should add
|
|
|
|
// ENDBR before catch pad instructions. For SjLj exception model, it will
|
|
|
|
// create a new BB(new landingpad) indirectly jump to the old landingpad.
|
|
|
|
if (TM->Options.ExceptionModel == ExceptionHandling::SjLj) {
|
|
|
|
for (MachineBasicBlock::iterator I = MBB.begin(); I != MBB.end(); ++I) {
|
|
|
|
// New Landingpad BB without EHLabel.
|
|
|
|
if (MBB.isEHPad()) {
|
|
|
|
if (I->isDebugInstr())
|
|
|
|
continue;
|
|
|
|
Changed |= addENDBR(MBB, I);
|
|
|
|
break;
|
|
|
|
} else if (I->isEHLabel()) {
|
|
|
|
// Old Landingpad BB (is not Landingpad now) with
|
|
|
|
// the the old "callee" EHLabel.
|
|
|
|
MCSymbol *Sym = I->getOperand(0).getMCSymbol();
|
|
|
|
if (!MF.hasCallSiteLandingPad(Sym))
|
|
|
|
continue;
|
|
|
|
Changed |= addENDBR(MBB, std::next(I));
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
} else if (MBB.isEHPad()){
|
|
|
|
for (MachineBasicBlock::iterator I = MBB.begin(); I != MBB.end(); ++I) {
|
|
|
|
if (!I->isEHLabel())
|
|
|
|
continue;
|
Enable IBT(Indirect Branch Tracking) in JIT with CET(Control-flow Enforcement Technology)
Do not commit the llvm/test/ExecutionEngine/MCJIT/cet-code-model-lager.ll because it will
cause build bot fail(not suitable for window 32 target).
Summary:
This patch comes from H.J.'s https://github.com/hjl-tools/llvm-project/commit/2bd54ce7fa9e94fcd1118b948e14d1b6fc54dfd2
**This patch fix the failed llvm unit tests which running on CET machine. **(e.g. ExecutionEngine/MCJIT/MCJITTests)
The reason we enable IBT at "JIT compiled with CET" is mainly that: the JIT don't know the its caller program is CET enable or not.
If JIT's caller program is non-CET, it is no problem JIT generate CET code or not.
But if JIT's caller program is CET enabled, JIT must generate CET code or it will cause Control protection exceptions.
I have test the patch at llvm-unit-test and llvm-test-suite at CET machine. It passed.
and H.J. also test it at building and running VNCserver(Virtual Network Console), it works too.
(if not apply this patch, VNCserver will crash at CET machine.)
Reviewers: hjl.tools, craig.topper, LuoYuanke, annita.zhang, pengfei
Reviewed By: LuoYuanke
Subscribers: tstellar, efriedma, hiraditya, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D76900
2020-04-07 08:59:13 +08:00
|
|
|
Changed |= addENDBR(MBB, std::next(I));
|
2020-04-20 10:17:34 +08:00
|
|
|
break;
|
2020-03-18 12:39:49 +08:00
|
|
|
}
|
2019-05-22 08:50:21 +08:00
|
|
|
}
|
|
|
|
}
|
2018-01-09 16:51:18 +08:00
|
|
|
return Changed;
|
|
|
|
}
|