en Copyright 2015 Java http://src.rcs.uwaterloo.ca:8080/source/history/llvm-project/llvm/lib/Target/AArch64/AArch64BranchTargets.cpp#018ac7847bb5a18ff68cf05b1d68f37fb32792d8 [AArch64] Add SEH_Nop opcodes for BTI hintsThese are harmless for the unwinder - the unwinder doesn't need tohandle them for being able to unwind correctly.Only add the opcodes when the branch target is in a SEH prologue;for jumptables e.g. within a function, we shouldn't add any SEHopcodes.Differential Revision: https://reviews.llvm.org/D135277 List of files: /llvm-project/llvm/lib/Target/AArch64/AArch64BranchTargets.cpp Wed, 05 Oct 2022 10:49:20 +0000 Martin Storsjö <martin@martin.st> http://src.rcs.uwaterloo.ca:8080/source/history/llvm-project/llvm/lib/Target/AArch64/AArch64BranchTargets.cpp#b1f463dcae3aafadac2b6a36583f38dea6a7136e [AArch64] Fix for BTI landing pad insertion with PAC-RET+bkey.EMITBKEY is emitted for PAC-RET+bkey, which is a non machine instructions.PR: 49957Reviewed By: eugenisDifferential Revision: https://reviews.llvm.org/D100996 List of files: /llvm-project/llvm/lib/Target/AArch64/AArch64BranchTargets.cpp Fri, 23 Apr 2021 08:06:15 +0000 Daniel Kiss <daniel.kiss@arm.com> http://src.rcs.uwaterloo.ca:8080/source/history/llvm-project/llvm/lib/Target/AArch64/AArch64BranchTargets.cpp#cca40aa8d8aa732a226c8978e53cd47e7b7c76ec [AArch64][v8.5A] Add BTI to all function startsThe existing BTI placement pass avoids inserting "BTI c" when thefunction has local linkage and is only directly called. However,even in this case, there is a (small) chance that the linker lateradds a hunk with an indirect call to the function, e.g. if thefunction is placed in a separate section and moved far away fromits callers. Make sure to add BTI for these functions too.Differential Revision: https://reviews.llvm.org/D99417 List of files: /llvm-project/llvm/lib/Target/AArch64/AArch64BranchTargets.cpp Wed, 24 Mar 2021 11:03:05 +0000 Pablo Barrio <pablo.barrio@arm.com> http://src.rcs.uwaterloo.ca:8080/source/history/llvm-project/llvm/lib/Target/AArch64/AArch64BranchTargets.cpp#a88c722e687e6780dcd6a58718350dc76fcc4cc9 [AArch64] PAC/BTI code generation for LLVM generated functionsPAC/BTI-related codegen in the AArch64 backend is controlled by a setof LLVM IR function attributes, added to the function by Clang, basedon command-line options and GCC-style function attributes. However,functions, generated in the LLVM middle end (for example,asan.module.ctor or __llvm_gcov_write_out) do not get any attributesand the backend incorrectly does not do any PAC/BTI code generation.This patch record the default state of PAC/BTI codegen in a set ofLLVM IR module-level attributes, based on command-line options:* "sign-return-address", with non-zero value means generate code to sign return addresses (PAC-RET), zero value means disable PAC-RET.* "sign-return-address-all", with non-zero value means enable PAC-RET for all functions, zero value means enable PAC-RET only for functions, which spill LR.* "sign-return-address-with-bkey", with non-zero value means use B-key for signing, zero value mean use A-key.This set of attributes are always added for AArch64 targets (asopposed, for example, to interpreting a missing attribute as having avalue 0) in order to be able to check for conflicts when combiningmodule attributed during LTO.Module-level attributes are overridden by function level attributes.All the decision making about whether to not to generate PAC and/orBTI code is factored out into AArch64FunctionInfo, there shouldn't beany places left, other than AArch64FunctionInfo, which directlyexamine PAC/BTI attributes, except AArch64AsmPrinter.cpp, whichis/will-be handled by a separate patch.Differential Revision: https://reviews.llvm.org/D85649 List of files: /llvm-project/llvm/lib/Target/AArch64/AArch64BranchTargets.cpp Fri, 25 Sep 2020 10:45:22 +0000 Momchil Velikov <momchil.velikov@arm.com> http://src.rcs.uwaterloo.ca:8080/source/history/llvm-project/llvm/lib/Target/AArch64/AArch64BranchTargets.cpp#b8ae3fdfa579dbf366b1bb1cbfdbf8c51db7fa55 [AArch64] Fix BTI instruction emission.Summary:SCTLR_EL1.BT[01] controls the PACI[AB]SP compatibility with PBYTE 11(see [1])This bit will be set to zero so PACI[AB]SP are equal to BTI Cinstruction only.[1] https://developer.arm.com/docs/ddi0595/b/aarch64-system-registers/sctlr_el1Reviewers: chill, tamas.petz, pbarrio, ostannardReviewed By: tamas.petz, ostannardSubscribers: kristof.beyls, hiraditya, llvm-commitsTags: #llvmDifferential Revision: https://reviews.llvm.org/D81746 List of files: /llvm-project/llvm/lib/Target/AArch64/AArch64BranchTargets.cpp Mon, 15 Jun 2020 13:02:38 +0000 Daniel Kiss <daniel.kiss@arm.com> http://src.rcs.uwaterloo.ca:8080/source/history/llvm-project/llvm/lib/Target/AArch64/AArch64BranchTargets.cpp#d5a186a60014dc1a8c979c978cb32aba7ecb9102 [AArch64] Fix BTI landing pad generation.In some cases BTI landing pad is inserted even compatible instructionwas there already. Meta instruction does not count in this casetherefore skip them in the check for first instructions in the function.Differential revision: https://reviews.llvm.org/D74492 List of files: /llvm-project/llvm/lib/Target/AArch64/AArch64BranchTargets.cpp Thu, 13 Feb 2020 10:42:39 +0000 Daniel Kiss <daniel.kiss@arm.com> http://src.rcs.uwaterloo.ca:8080/source/history/llvm-project/llvm/lib/Target/AArch64/AArch64BranchTargets.cpp#2946cd701067404b99c39fb29dc9c74bd7193eb3 Update the file headers across all of the LLVM projects in the monorepoto reflect the new license.We understand that people may be surprised that we're moving the headerentirely to discuss the new license. We checked this carefully with theFoundation's lawyer and we believe this is the correct approach.Essentially, all code in the project is now made available by the LLVMproject under our new license, so you will see that the license headersinclude that license only. Some of our contributors have contributedcode under our old license, and accordingly, we have retained a copy ofour old license notice in the top-level files in each project andrepository.llvm-svn: 351636 List of files: /llvm-project/llvm/lib/Target/AArch64/AArch64BranchTargets.cpp Sat, 19 Jan 2019 08:50:56 +0000 Chandler Carruth <chandlerc@gmail.com> http://src.rcs.uwaterloo.ca:8080/source/history/llvm-project/llvm/lib/Target/AArch64/AArch64BranchTargets.cpp#250e5a5b655f67d58470533a7b21ce38d7946d50 [AArch64][v8.5A] Branch Target Identification code-generation passThe Branch Target Identification extension, introduced to AArch64 inArmv8.5-A, adds the BTI instruction, which is used to mark valid targetsof indirect branches. When enabled, the processor will trap if aninstruction in a protected page tries to perform an indirect branch toany instruction other than a BTI. The BTI instruction uses encodingswhich were NOPs in earlier versions of the architecture, so BTI-enabledcode will still run on earlier hardware, just without the extraprotection.There are 3 variants of the BTI instruction, which are valid targets fordifferent 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 targetidentification, the reason for this is that return addresses can beprotected more effectively using return address signing. Direct branchesand calls are also unaffected, as it is assumed that an attacker cannotmodify executable pages (if they could, they wouldn't need to do aROP/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, andtakes the address of the entry block. I've not been able to trigger thisfrom 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 inBTI-protected pages uses indirect tail-calls, unless they use x16 or x17to hold the address. I'll add that code-generation restriction as aseparate patch.Differential revision: https://reviews.llvm.org/D52867llvm-svn: 343967 List of files: /llvm-project/llvm/lib/Target/AArch64/AArch64BranchTargets.cpp Mon, 08 Oct 2018 14:04:24 +0000 Oliver Stannard <oliver.stannard@arm.com>