Browse files

[AArch64][v8.5A] Branch Target Identification code-generation pass

The Branch Target Identification extension, introduced to AArch64 in
Armv8.5-A, adds the BTI instruction, which is used to mark valid targets
of indirect branches. When enabled, the processor will trap if an
instruction in a protected page tries to perform an indirect branch to
any instruction other than a BTI. The BTI instruction uses encodings
which were NOPs in earlier versions of the architecture, so BTI-enabled
code will still run on earlier hardware, just without the extra

There are 3 variants of the BTI instruction, which are valid targets for
different kinds or branches:
- BTI C can be targeted by call instructions, and is inteneded to be
  used at function entry points. These are the BLR instruction, as well
  as BR with x16 or x17. These BR instructions are allowed for use in
  PLT entries, and we can also use them to allow indirect tail-calls.
- BTI J can be targeted by BR only, and is intended to be used by jump
- BTI JC acts ab both a BTI C and a BTI J instruction, and can be
  targeted by any BLR or BR instruction.

Note that RET instructions are not restricted by branch target
identification, the reason for this is that return addresses can be
protected more effectively using return address signing. Direct branches
and calls are also unaffected, as it is assumed that an attacker cannot
modify executable pages (if they could, they wouldn't need to do a
ROP/JOP attack).

This patch adds a MachineFunctionPass which:
- Adds a BTI C at the start of every function which could be indirectly
  called (either because it is address-taken, or externally visible so
  could be address-taken in another translation unit).
- Adds a BTI J at the start of every basic block which could be
  indirectly branched to. This could be either done by a jump table, or
  by taking the address of the block (e.g. the using GCC label values

We only need to use BTI JC when a function is indirectly-callable, and
takes the address of the entry block. I've not been able to trigger this
from C or IR, but I've included a MIR test just in case.

Using BTI C at function entries relies on the fact that no other code in
BTI-protected pages uses indirect tail-calls, unless they use x16 or x17
to hold the address. I'll add that code-generation restriction as a
separate patch.

Differential revision:

git-svn-id: 91177308-0d34-0410-b5e6-96231b3b80d8
  • Loading branch information...
Oliver Stannard
Oliver Stannard committed Oct 8, 2018
1 parent c190984 commit 4bc81028d48c0ab07e7b429d2a98ed6d15140a23
@@ -46,6 +46,7 @@ FunctionPass *createAArch64A57FPLoadBalancing();
FunctionPass *createAArch64A53Fix835769();
FunctionPass *createFalkorHWPFFixPass();
FunctionPass *createFalkorMarkStridedAccessesPass();
FunctionPass *createAArch64BranchTargetsPass();
FunctionPass *createAArch64CleanupLocalDynamicTLSPass();
@@ -58,6 +59,7 @@ FunctionPass *createAArch64PreLegalizeCombiner();
void initializeAArch64A53Fix835769Pass(PassRegistry&);
void initializeAArch64A57FPLoadBalancingPass(PassRegistry&);
void initializeAArch64AdvSIMDScalarPass(PassRegistry&);
void initializeAArch64BranchTargetsPass(PassRegistry&);
void initializeAArch64CollectLOHPass(PassRegistry&);
void initializeAArch64CondBrTuningPass(PassRegistry &);
void initializeAArch64ConditionalComparesPass(PassRegistry&);
@@ -0,0 +1,130 @@
//===-- AArch64BranchTargets.cpp -- Harden code using v8.5-A BTI extension -==//
// The LLVM Compiler Infrastructure
// This file is distributed under the University of Illinois Open Source
// License. See LICENSE.TXT for details.
// This pass inserts BTI instructions at the start of every function and basic
// block which could be indirectly called. The hardware will (when enabled)
// trap when an indirect branch or call instruction targets an instruction
// which is not a valid BTI instruction. This is intended to guard against
// control-flow hijacking attacks. Note that this does not do anything for RET
// instructions, as they can be more precisely protected by return address
// signing.
#include "AArch64Subtarget.h"
#include "llvm/CodeGen/MachineFunctionPass.h"
#include "llvm/CodeGen/MachineInstrBuilder.h"
#include "llvm/CodeGen/MachineJumpTableInfo.h"
#include "llvm/CodeGen/MachineModuleInfo.h"
#include "llvm/Support/Debug.h"
using namespace llvm;
#define DEBUG_TYPE "aarch64-branch-targets"
#define AARCH64_BRANCH_TARGETS_NAME "AArch64 Branch Targets"
namespace {
class AArch64BranchTargets : public MachineFunctionPass {
static char ID;
AArch64BranchTargets() : MachineFunctionPass(ID) {}
void getAnalysisUsage(AnalysisUsage &AU) const override;
bool runOnMachineFunction(MachineFunction &MF) override;
StringRef getPassName() const override { return AARCH64_BRANCH_TARGETS_NAME; }
void addBTI(MachineBasicBlock &MBB, bool CouldCall, bool CouldJump);
} // end anonymous namespace
char AArch64BranchTargets::ID = 0;
INITIALIZE_PASS(AArch64BranchTargets, "aarch64-branch-targets",
void AArch64BranchTargets::getAnalysisUsage(AnalysisUsage &AU) const {
FunctionPass *llvm::createAArch64BranchTargetsPass() {
return new AArch64BranchTargets();
bool AArch64BranchTargets::runOnMachineFunction(MachineFunction &MF) {
const Function &F = MF.getFunction();
if (!F.hasFnAttribute("branch-target-enforcement"))
return false;
dbgs() << "********** AArch64 Branch Targets **********\n"
<< "********** Function: " << MF.getName() << '\n');
// LLVM does not consider basic blocks which are the targets of jump tables
// to be address-taken (the address can't escape anywhere else), but they are
// used for indirect branches, so need BTI instructions.
SmallPtrSet<MachineBasicBlock *, 8> JumpTableTargets;
if (auto *JTI = MF.getJumpTableInfo())
for (auto &JTE : JTI->getJumpTables())
for (auto *MBB : JTE.MBBs)
bool MadeChange = false;
for (MachineBasicBlock &MBB : MF) {
bool CouldCall = false, CouldJump = false;
// If the function is address-taken or externally-visible, it could be
// indirectly called. PLT entries and tail-calls use BR, but when they are
// are in guarded pages should all use x16 or x17 to hold the called
// address, so we don't need to set CouldJump here. BR instructions in
// non-guarded pages (which might be non-BTI-aware code) are allowed to
// branch to a "BTI c" using any register.
if (&MBB == &*MF.begin() && (F.hasAddressTaken() || !F.hasLocalLinkage()))
CouldCall = true;
// If the block itself is address-taken, it could be indirectly branched
// to, but not called.
if (MBB.hasAddressTaken() || JumpTableTargets.count(&MBB))
CouldJump = true;
if (CouldCall || CouldJump) {
addBTI(MBB, CouldCall, CouldJump);
MadeChange = true;
return MadeChange;
void AArch64BranchTargets::addBTI(MachineBasicBlock &MBB, bool CouldCall,
bool CouldJump) {
LLVM_DEBUG(dbgs() << "Adding BTI " << (CouldJump ? "j" : "")
<< (CouldCall ? "c" : "") << " to " << MBB.getName()
<< "\n");
const AArch64InstrInfo *TII = static_cast<const AArch64InstrInfo *>(
unsigned HintNum = 32;
if (CouldCall)
HintNum |= 2;
if (CouldJump)
HintNum |= 4;
assert(HintNum != 32 && "No target kinds!");
auto MBBI = MBB.begin();
// PACI[AB]SP are implicitly BTI JC, so no BTI instruction needed there.
if (MBBI != MBB.end() && (MBBI->getOpcode() == AArch64::PACIASP ||
MBBI->getOpcode() == AArch64::PACIBSP))
BuildMI(MBB, MBB.begin(), MBB.findDebugLoc(MBB.begin()),
@@ -141,6 +141,11 @@ static cl::opt<int> EnableGlobalISelAtO(
static cl::opt<bool> EnableFalkorHWPFFix("aarch64-enable-falkor-hwpf-fix",
cl::init(true), cl::Hidden);
static cl::opt<bool>
EnableBranchTargets("aarch64-enable-branch-targets", cl::Hidden,
cl::desc("Enable the AAcrh64 branch target pass"),
extern "C" void LLVMInitializeAArch64Target() {
// Register the target.
RegisterTargetMachine<AArch64leTargetMachine> X(getTheAArch64leTarget());
@@ -151,6 +156,7 @@ extern "C" void LLVMInitializeAArch64Target() {
@@ -537,6 +543,9 @@ void AArch64PassConfig::addPreEmitPass() {
if (BranchRelaxation)
if (EnableBranchTargets)
if (TM->getOptLevel() != CodeGenOpt::None && EnableCollectLOH &&
@@ -22,6 +22,7 @@ add_llvm_target(AArch64CodeGen
@@ -52,6 +52,7 @@
; CHECK-NEXT: AArch64 pseudo instruction expansion pass
; CHECK-NEXT: Analyze Machine Code For Garbage Collection
; CHECK-NEXT: Branch relaxation pass
; CHECK-NEXT: AArch64 Branch Targets
; CHECK-NEXT: Contiguously Lay Out Funclets
; CHECK-NEXT: StackMap Liveness Analysis
@@ -150,6 +150,7 @@
; CHECK-NEXT: MachinePostDominator Tree Construction
; CHECK-NEXT: Branch Probability Basic Block Placement
; CHECK-NEXT: Branch relaxation pass
; CHECK-NEXT: AArch64 Branch Targets
; CHECK-NEXT: Contiguously Lay Out Funclets
; CHECK-NEXT: StackMap Liveness Analysis
Oops, something went wrong.

0 comments on commit 4bc8102

Please sign in to comment.