2018-03-23 07:02:48 +08:00
|
|
|
; RUN: llc -mtriple=arm64-- -O0 -debug-pass=Structure < %s -o /dev/null 2>&1 | grep -v "Verify generated machine code" | FileCheck %s
|
|
|
|
|
|
|
|
|
|
; REQUIRES: asserts
|
|
|
|
|
|
|
|
|
|
; CHECK-LABEL: Pass Arguments:
|
|
|
|
|
; CHECK-NEXT: Target Library Information
|
|
|
|
|
; CHECK-NEXT: Target Pass Configuration
|
|
|
|
|
; CHECK-NEXT: Machine Module Information
|
|
|
|
|
; CHECK-NEXT: Target Transform Information
|
|
|
|
|
; CHECK-NEXT: Type-Based Alias Analysis
|
|
|
|
|
; CHECK-NEXT: Scoped NoAlias Alias Analysis
|
|
|
|
|
; CHECK-NEXT: Assumption Cache Tracker
|
|
|
|
|
; CHECK-NEXT: Create Garbage Collector Module Metadata
|
|
|
|
|
; CHECK-NEXT: Machine Branch Probability Analysis
|
|
|
|
|
; CHECK-NEXT: ModulePass Manager
|
|
|
|
|
; CHECK-NEXT: Pre-ISel Intrinsic Lowering
|
|
|
|
|
; CHECK-NEXT: FunctionPass Manager
|
|
|
|
|
; CHECK-NEXT: Expand Atomic instructions
|
|
|
|
|
; CHECK-NEXT: Dominator Tree Construction
|
|
|
|
|
; CHECK-NEXT: Basic Alias Analysis (stateless AA impl)
|
|
|
|
|
; CHECK-NEXT: Module Verifier
|
|
|
|
|
; CHECK-NEXT: Lower Garbage Collection Instructions
|
|
|
|
|
; CHECK-NEXT: Shadow Stack GC Lowering
|
|
|
|
|
; CHECK-NEXT: Remove unreachable blocks from the CFG
|
|
|
|
|
; CHECK-NEXT: Instrument function entry/exit with calls to e.g. mcount() (post inlining)
|
|
|
|
|
; CHECK-NEXT: Scalarize Masked Memory Intrinsics
|
|
|
|
|
; CHECK-NEXT: Expand reduction intrinsics
|
|
|
|
|
; CHECK-NEXT: Rewrite Symbols
|
|
|
|
|
; CHECK-NEXT: FunctionPass Manager
|
|
|
|
|
; CHECK-NEXT: Dominator Tree Construction
|
|
|
|
|
; CHECK-NEXT: Exception handling preparation
|
|
|
|
|
; CHECK-NEXT: Safe Stack instrumentation pass
|
|
|
|
|
; CHECK-NEXT: Insert stack protectors
|
|
|
|
|
; CHECK-NEXT: Module Verifier
|
2019-01-16 08:40:37 +08:00
|
|
|
; CHECK-NEXT: Analysis containing CSE Info
|
2018-03-23 07:02:48 +08:00
|
|
|
; CHECK-NEXT: IRTranslator
|
Re-commit: [globalisel] Add a combiner helpers for extending loads and use them in a pre-legalize combiner for AArch64
Summary: Depends on D45541
Reviewers: ab, aditya_nandakumar, bogner, rtereshin, volkan, rovka, javed.absar, aemerson
Subscribers: aemerson, rengolin, mgorny, javed.absar, kristof.beyls, llvm-commits
Differential Revision: https://reviews.llvm.org/D45543
The previous commit failed portions of the test-suite on GreenDragon due to
duplicate COPY instructions and iterator invalidation. Both issues have now
been fixed. To assist with this, a helper (cloneVirtualRegister) has been added
to MachineRegisterInfo that can be used to get another register that has the same
type and class/bank as an existing one.
llvm-svn: 343654
2018-10-03 10:12:17 +08:00
|
|
|
; CHECK-NEXT: AArch64PreLegalizerCombiner
|
2019-01-16 08:40:37 +08:00
|
|
|
; CHECK-NEXT: Analysis containing CSE Info
|
2018-03-23 07:02:48 +08:00
|
|
|
; CHECK-NEXT: Legalizer
|
|
|
|
|
; CHECK-NEXT: RegBankSelect
|
|
|
|
|
; CHECK-NEXT: Localizer
|
|
|
|
|
; CHECK-NEXT: InstructionSelect
|
|
|
|
|
; CHECK-NEXT: ResetMachineFunction
|
|
|
|
|
; CHECK-NEXT: AArch64 Instruction Selection
|
2019-06-19 08:25:39 +08:00
|
|
|
; CHECK-NEXT: Finalize ISel and expand pseudo-instructions
|
2018-03-23 07:02:48 +08:00
|
|
|
; CHECK-NEXT: Local Stack Slot Allocation
|
|
|
|
|
; CHECK-NEXT: Eliminate PHI nodes for register allocation
|
|
|
|
|
; CHECK-NEXT: Two-Address instruction pass
|
|
|
|
|
; CHECK-NEXT: Fast Register Allocator
|
|
|
|
|
; CHECK-NEXT: Lazy Machine Block Frequency Analysis
|
|
|
|
|
; CHECK-NEXT: Machine Optimization Remark Emitter
|
|
|
|
|
; CHECK-NEXT: Prologue/Epilogue Insertion & Frame Finalization
|
|
|
|
|
; CHECK-NEXT: Post-RA pseudo instruction expansion pass
|
|
|
|
|
; CHECK-NEXT: AArch64 pseudo instruction expansion pass
|
Introduce control flow speculation tracking pass for AArch64
The pass implements tracking of control flow miss-speculation into a "taint"
register. That taint register can then be used to mask off registers with
sensitive data when executing under miss-speculation, a.k.a. "transient
execution".
This pass is aimed at mitigating against SpectreV1-style vulnarabilities.
At the moment, it implements the tracking of miss-speculation of control
flow into a taint register, but doesn't implement a mechanism yet to then
use that taint register to mask off vulnerable data in registers (something
for a follow-on improvement). Possible strategies to mask out vulnerable
data that can be implemented on top of this are:
- speculative load hardening to automatically mask of data loaded
in registers.
- using intrinsics to mask of data in registers as indicated by the
programmer (see https://lwn.net/Articles/759423/).
For AArch64, the following implementation choices are made.
Some of these are different than the implementation choices made in
the similar pass implemented in X86SpeculativeLoadHardening.cpp, as
the instruction set characteristics result in different trade-offs.
- The speculation hardening is done after register allocation. With a
relative abundance of registers, one register is reserved (X16) to be
the taint register. X16 is expected to not clash with other register
reservation mechanisms with very high probability because:
. The AArch64 ABI doesn't guarantee X16 to be retained across any call.
. The only way to request X16 to be used as a programmer is through
inline assembly. In the rare case a function explicitly demands to
use X16/W16, this pass falls back to hardening against speculation
by inserting a DSB SYS/ISB barrier pair which will prevent control
flow speculation.
- It is easy to insert mask operations at this late stage as we have
mask operations available that don't set flags.
- The taint variable contains all-ones when no miss-speculation is detected,
and contains all-zeros when miss-speculation is detected. Therefore, when
masking, an AND instruction (which only changes the register to be masked,
no other side effects) can easily be inserted anywhere that's needed.
- The tracking of miss-speculation is done by using a data-flow conditional
select instruction (CSEL) to evaluate the flags that were also used to
make conditional branch direction decisions. Speculation of the CSEL
instruction can be limited with a CSDB instruction - so the combination of
CSEL + a later CSDB gives the guarantee that the flags as used in the CSEL
aren't speculated. When conditional branch direction gets miss-speculated,
the semantics of the inserted CSEL instruction is such that the taint
register will contain all zero bits.
One key requirement for this to work is that the conditional branch is
followed by an execution of the CSEL instruction, where the CSEL
instruction needs to use the same flags status as the conditional branch.
This means that the conditional branches must not be implemented as one
of the AArch64 conditional branches that do not use the flags as input
(CB(N)Z and TB(N)Z). This is implemented by ensuring in the instruction
selectors to not produce these instructions when speculation hardening
is enabled. This pass will assert if it does encounter such an instruction.
- On function call boundaries, the miss-speculation state is transferred from
the taint register X16 to be encoded in the SP register as value 0.
Future extensions/improvements could be:
- Implement this functionality using full speculation barriers, akin to the
x86-slh-lfence option. This may be more useful for the intrinsics-based
approach than for the SLH approach to masking.
Note that this pass already inserts the full speculation barriers if the
function for some niche reason makes use of X16/W16.
- no indirect branch misprediction gets protected/instrumented; but this
could be done for some indirect branches, such as switch jump tables.
Differential Revision: https://reviews.llvm.org/D54896
llvm-svn: 349456
2018-12-18 16:50:02 +08:00
|
|
|
; CHECK-NEXT: AArch64 speculation hardening pass
|
2018-03-23 07:02:48 +08:00
|
|
|
; CHECK-NEXT: Analyze Machine Code For Garbage Collection
|
|
|
|
|
; CHECK-NEXT: Branch relaxation pass
|
[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
protection.
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
tables.
- 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
extension).
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: https://reviews.llvm.org/D52867
llvm-svn: 343967
2018-10-08 22:04:24 +08:00
|
|
|
; CHECK-NEXT: AArch64 Branch Targets
|
2018-03-23 07:02:48 +08:00
|
|
|
; CHECK-NEXT: Contiguously Lay Out Funclets
|
|
|
|
|
; CHECK-NEXT: StackMap Liveness Analysis
|
|
|
|
|
; CHECK-NEXT: Live DEBUG_VALUE analysis
|
|
|
|
|
; CHECK-NEXT: Insert fentry calls
|
|
|
|
|
; CHECK-NEXT: Insert XRay ops
|
|
|
|
|
; CHECK-NEXT: Implement the 'patchable-function' attribute
|
|
|
|
|
; CHECK-NEXT: Lazy Machine Block Frequency Analysis
|
|
|
|
|
; CHECK-NEXT: Machine Optimization Remark Emitter
|
|
|
|
|
; CHECK-NEXT: AArch64 Assembly Printer
|
|
|
|
|
; CHECK-NEXT: Free MachineFunction
|
|
|
|
|
|
|
|
|
|
define void @f() {
|
|
|
|
|
ret void
|
|
|
|
|
}
|