[llvm-branch-commits] [llvm] [AArch64][PAC] Support BLRA* instructions in SLS Hardening pass (PR #97605)

[Kristof Beyls via llvm-branch-commits]

@@ -139,64 +262,59 @@ bool 
SLSHardeningInserter::hardenReturnsAndBRs(MachineModuleInfo ,
   return Modified;
 }
 
-static const unsigned NumPermittedRegs = 29;
-static const struct ThunkNameAndReg {
-  const char* Name;
-  Register Reg;
-} SLSBLRThunks[NumPermittedRegs] = {
-{"__llvm_slsblr_thunk_x0", AArch64::X0},
-{"__llvm_slsblr_thunk_x1", AArch64::X1},
-{"__llvm_slsblr_thunk_x2", AArch64::X2},
-{"__llvm_slsblr_thunk_x3", AArch64::X3},
-{"__llvm_slsblr_thunk_x4", AArch64::X4},
-{"__llvm_slsblr_thunk_x5", AArch64::X5},
-{"__llvm_slsblr_thunk_x6", AArch64::X6},
-{"__llvm_slsblr_thunk_x7", AArch64::X7},
-{"__llvm_slsblr_thunk_x8", AArch64::X8},
-{"__llvm_slsblr_thunk_x9", AArch64::X9},
-{"__llvm_slsblr_thunk_x10", AArch64::X10},
-{"__llvm_slsblr_thunk_x11", AArch64::X11},
-{"__llvm_slsblr_thunk_x12", AArch64::X12},
-{"__llvm_slsblr_thunk_x13", AArch64::X13},
-{"__llvm_slsblr_thunk_x14", AArch64::X14},
-{"__llvm_slsblr_thunk_x15", AArch64::X15},
-// X16 and X17 are deliberately missing, as the mitigation requires those
-// register to not be used in BLR. See comment in ConvertBLRToBL for more
-// details.
-{"__llvm_slsblr_thunk_x18", AArch64::X18},
-{"__llvm_slsblr_thunk_x19", AArch64::X19},
-{"__llvm_slsblr_thunk_x20", AArch64::X20},
-{"__llvm_slsblr_thunk_x21", AArch64::X21},
-{"__llvm_slsblr_thunk_x22", AArch64::X22},
-{"__llvm_slsblr_thunk_x23", AArch64::X23},
-{"__llvm_slsblr_thunk_x24", AArch64::X24},
-{"__llvm_slsblr_thunk_x25", AArch64::X25},
-{"__llvm_slsblr_thunk_x26", AArch64::X26},
-{"__llvm_slsblr_thunk_x27", AArch64::X27},
-{"__llvm_slsblr_thunk_x28", AArch64::X28},
-{"__llvm_slsblr_thunk_x29", AArch64::FP},
-// X30 is deliberately missing, for similar reasons as X16 and X17 are
-// missing.
-{"__llvm_slsblr_thunk_x31", AArch64::XZR},
-};
+// Currently, the longest possible thunk name is
+//   __llvm_slsblr_thunk_aa_xNN_xMM
+// which is 31 characters (without the '\0' character).
+static SmallString<32> createThunkName(const ThunkKind , Register Xn,
+   Register Xm) {
+  unsigned N = ThunksSet::indexOfXReg(Xn);
+  if (!Kind.HasXmOperand)
+return formatv("{0}{1}x{2}", CommonNamePrefix, Kind.NameInfix, N);
+
+  unsigned M = ThunksSet::indexOfXReg(Xm);
+  return formatv("{0}{1}x{2}_x{3}", CommonNamePrefix, Kind.NameInfix, N, M);
+}
 
-unsigned getThunkIndex(Register Reg) {
-  for (unsigned I = 0; I < NumPermittedRegs; ++I)
-if (SLSBLRThunks[I].Reg == Reg)
-  return I;
-  llvm_unreachable("Unexpected register");
+static const ThunkKind (StringRef ThunkName, Register ,

kbeyls wrote:

Again a very minor nitpick: I was a bit confused initially that the 3 results 
of this function are returned split between function return value (ThunkKind) 
and 2 pass-by-reference function arguments (Xn, Xm).
Would it be better to either return all 3 of them through a function return 
value, or return all 3 of them through pass-by-reference function arguments?
I'm just sharing it in case you think it's worthwhile to make such a change.

https://github.com/llvm/llvm-project/pull/97605
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [llvm] [AArch64][PAC] Support BLRA* instructions in SLS Hardening pass (PR #97605)

[Kristof Beyls via llvm-branch-commits]

@@ -221,13 +339,19 @@ void SLSHardeningInserter::populateThunk(MachineFunction 
) {
   //  __llvm_slsblr_thunk_xN:
   //  BR xN
   //  barrierInsts

kbeyls wrote:

As part of reviewing this, I was wondering why the actual thunk content is
```
  //  __llvm_slsblr_thunk_{aa|ab|aaz|abz|}_xN_{xM}:
  //  MOV X16, Xn
  //  BR X16 | BRA{A|B} X16, Xm | BRA{A|B}Z X16
  //  barrierInsts
```

I had to use git blame to remind myself of why I changed this about 4 years ago,
pointing to this commit: 
https://github.com/llvm/llvm-project/commit/d938ec4509c47d461377527fc2877ae14b91275c

I think it would be useful to add an explanation similar to the one on that 
commit message
to the comment here to explain why the `mov X16, Xn` is needed, as
it is non-trivial. The explanation on the original commit message is:
```
A "BTI c" instruction only allows jumping/calling to using a BLR* instruction.
However, the SLSBLR mitigation changes a BLR to a BR to implement the
function call. Therefore, a "BTI c" check that passed before could
trigger after the BLR->BR change done by the SLSBLR mitigation.
However, if the register used in BR is X16 or X17, this trigger will not
fire (see ArmARM for further details).
```


https://github.com/llvm/llvm-project/pull/97605
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [llvm] [AArch64][PAC] Support BLRA* instructions in SLS Hardening pass (PR #97605)

[Kristof Beyls via llvm-branch-commits]

@@ -221,13 +339,19 @@ void SLSHardeningInserter::populateThunk(MachineFunction 
) {
   //  __llvm_slsblr_thunk_xN:
   //  BR xN
   //  barrierInsts

kbeyls wrote:

Maybe something like
```
  //  __llvm_slsblr_thunk_{aa|ab|aaz|abz|}_xN_{xM}:
  //  BR Xn | BRA{A|B} Xn, Xm | BRA{A|B}Z xN
  //  barrierInsts
```
?

https://github.com/llvm/llvm-project/pull/97605
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [llvm] [AArch64][PAC] Support BLRA* instructions in SLS Hardening pass (PR #97605)

[Kristof Beyls via llvm-branch-commits]

@@ -68,6 +156,57 @@ struct SLSHardeningInserter : 
ThunkInserter {
 
 } // end anonymous namespace
 
+const ThunkKind ThunkKind::BR = {ThunkBR, "", false, false, AArch64::BR};
+const ThunkKind ThunkKind::BRAA = {ThunkBRAA, "aa_", true, true, 
AArch64::BRAA};
+const ThunkKind ThunkKind::BRAB = {ThunkBRAB, "ab_", true, true, 
AArch64::BRAB};
+const ThunkKind ThunkKind::BRAAZ = {ThunkBRAAZ, "aaz_", false, true,
+AArch64::BRAAZ};
+const ThunkKind ThunkKind::BRABZ = {ThunkBRABZ, "abz_", false, true,
+AArch64::BRABZ};
+
+static const ThunkKind *getThunkKind(unsigned OriginalOpcode) {

kbeyls wrote:

very minor comment: I thought I'd just share that if I would've written this 
function, I'd probably use std::optional rather than a "pointer to" return 
value. But this is very nit-picky, so if you think "pointer to" is better, 
let's leave it as is.

https://github.com/llvm/llvm-project/pull/97605
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [llvm] [AArch64][PAC] Support BLRA* instructions in SLS Hardening pass (PR #97605)

[Kristof Beyls via llvm-branch-commits]

@@ -68,6 +156,57 @@ struct SLSHardeningInserter : 
ThunkInserter {
 
 } // end anonymous namespace
 
+const ThunkKind ThunkKind::BR = {ThunkBR, "", false, false, AArch64::BR};
+const ThunkKind ThunkKind::BRAA = {ThunkBRAA, "aa_", true, true, 
AArch64::BRAA};
+const ThunkKind ThunkKind::BRAB = {ThunkBRAB, "ab_", true, true, 
AArch64::BRAB};
+const ThunkKind ThunkKind::BRAAZ = {ThunkBRAAZ, "aaz_", false, true,
+AArch64::BRAAZ};
+const ThunkKind ThunkKind::BRABZ = {ThunkBRABZ, "abz_", false, true,
+AArch64::BRABZ};
+
+static const ThunkKind *getThunkKind(unsigned OriginalOpcode) {
+  switch (OriginalOpcode) {
+  case AArch64::BLR:
+  case AArch64::BLRNoIP:
+return ::BR;
+  case AArch64::BLRAA:
+return ::BRAA;
+  case AArch64::BLRAB:
+return ::BRAB;
+  case AArch64::BLRAAZ:
+return ::BRAAZ;
+  case AArch64::BLRABZ:
+return ::BRABZ;
+  }
+  return nullptr;
+}
+
+static bool isBLR(const MachineInstr ) {
+  return getThunkKind(MI.getOpcode()) != nullptr;
+}
+
+unsigned ThunksSet::indexOfXReg(Register Reg) {
+  assert(AArch64::GPR64RegClass.contains(Reg));
+  assert(Reg != AArch64::X16 && Reg != AArch64::X17 && Reg != AArch64::LR);
+
+  // Most Xn registers have consequent ids, except for FP and XZR.

kbeyls wrote:

s/consequent/consecutive/?

https://github.com/llvm/llvm-project/pull/97605
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [llvm] [AArch64][PAC] Support BLRA* instructions in SLS Hardening pass (PR #97605)

[Kristof Beyls via llvm-branch-commits]

@@ -221,13 +339,19 @@ void SLSHardeningInserter::populateThunk(MachineFunction 
) {
   //  __llvm_slsblr_thunk_xN:
   //  BR xN
   //  barrierInsts

kbeyls wrote:

I think it would be useful to update this comment to make it clear what the 
different kinds of thunk bodies are that are intended to be created here.

https://github.com/llvm/llvm-project/pull/97605
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [llvm] [AArch64][PAC] Support BLRA* instructions in SLS Hardening pass (PR #97605)

[Kristof Beyls via llvm-branch-commits]

@@ -0,0 +1,210 @@
+# RUN: llc -verify-machineinstrs -mtriple=aarch64-none-linux-gnu \
+# RUN: -start-before aarch64-sls-hardening -o - %s \
+# RUN: -asm-verbose=0 \
+# RUN: | FileCheck %s \
+# RUN: --implicit-check-not=__llvm_slsblr_thunk_aa_x5_x8 \
+# RUN: --implicit-check-not=__llvm_slsblr_thunk_ab_x5_x8 \
+# RUN: --implicit-check-not=__llvm_slsblr_thunk_aaz_x5 \
+# RUN: --implicit-check-not=__llvm_slsblr_thunk_abz_x5
+
+# Pointer Authentication extension introduces more branch-with-link 
instructions

kbeyls wrote:

Maybe say "branch-with-link-to-register" as that's the name the ArmARM (Arm 
Architecture reference manual) uses for BLR* instructions. "branch-with-link" 
to me refers to the BL instruction.

https://github.com/llvm/llvm-project/pull/97605
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [llvm] [AArch64][PAC] Support BLRA* instructions in SLS Hardening pass (PR #97605)

[Kristof Beyls via llvm-branch-commits]

@@ -274,40 +398,31 @@ void SLSHardeningInserter::convertBLRToBL(
 
   MachineInstr  = *MBBI;
   assert(isBLR(BLR));
-  unsigned BLOpcode;
-  Register Reg;
-  bool RegIsKilled;
-  switch (BLR.getOpcode()) {
-  case AArch64::BLR:
-  case AArch64::BLRNoIP:
-BLOpcode = AArch64::BL;
-Reg = BLR.getOperand(0).getReg();
-assert(Reg != AArch64::X16 && Reg != AArch64::X17 && Reg != AArch64::LR);
-RegIsKilled = BLR.getOperand(0).isKill();
-break;
-  case AArch64::BLRAA:
-  case AArch64::BLRAB:
-  case AArch64::BLRAAZ:
-  case AArch64::BLRABZ:
-llvm_unreachable("BLRA instructions cannot yet be produced by LLVM, "
- "therefore there is no need to support them for now.");
-  default:
-llvm_unreachable("unhandled BLR");
-  }
+  const ThunkKind  = *getThunkKind(BLR.getOpcode());

kbeyls wrote:

In the 20-line-ish long comment above (which I cannot comment on directly in 
github),
I think it would also be useful to indicate which branch instructions might be 
the authenticating ones. I think that might help the reader a bit better with 
more quickly understanding what the intended transform is. E.g. something like:
```
// Before:
  //   |-|
  //   |  ...|
  //   |  instI  |
  //   |  BLR{A|B|}{Z} xN{, xM}  |
  //   |  instJ  |
  //   |  ...|
  //   |-|
  //
  // After:
  //   |-|
  //   |  ...|
  //   |  instI  |
  //   |  BL __llvm_slsblr_thunk_xN  |
  //   |  instJ  |
  //   |  ...|
  //   |-|
  //
  //   __llvm_slsblr_thunk_xN:
  //   |-|
  //   |  BR{A|B|}{Z} xN{, xM}   |
  //   |  barrierInsts   |
  //   |-|
//
```

https://github.com/llvm/llvm-project/pull/97605
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [llvm] [AArch64][PAC] Support BLRA* instructions in SLS Hardening pass (PR #97605)

[Kristof Beyls via llvm-branch-commits]

https://github.com/kbeyls commented:

Thank you, this mostly looks good to me.
I've only added very minor comments; feel free to disagree with them.

https://github.com/llvm/llvm-project/pull/97605
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [llvm] [AArch64][PAC] Support BLRA* instructions in SLS Hardening pass (PR #97605)

[Kristof Beyls via llvm-branch-commits]

https://github.com/kbeyls edited https://github.com/llvm/llvm-project/pull/97605
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [llvm] [AArch64][PAC] Support BLRA* instructions in SLS Hardening pass (PR #97605)

[Kristof Beyls via llvm-branch-commits]

@@ -68,6 +156,57 @@ struct SLSHardeningInserter : 
ThunkInserter {
 
 } // end anonymous namespace
 
+const ThunkKind ThunkKind::BR = {ThunkBR, "", false, false, AArch64::BR};
+const ThunkKind ThunkKind::BRAA = {ThunkBRAA, "aa_", true, true, 
AArch64::BRAA};
+const ThunkKind ThunkKind::BRAB = {ThunkBRAB, "ab_", true, true, 
AArch64::BRAB};
+const ThunkKind ThunkKind::BRAAZ = {ThunkBRAAZ, "aaz_", false, true,
+AArch64::BRAAZ};
+const ThunkKind ThunkKind::BRABZ = {ThunkBRABZ, "abz_", false, true,
+AArch64::BRABZ};

kbeyls wrote:

very minor nitpick: These probably can go directly after the definition of 
`struct ThunkKind`?
If so, it's easier to understand what all the "false" and "true"s mean here 
without having to scroll a lot to where `struct ThunkKind` is defined.

https://github.com/llvm/llvm-project/pull/97605
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [llvm] [AArch64] Only create called thunks when hardening against SLS (PR #97472)

[Kristof Beyls via llvm-branch-commits]

@@ -36,38 +32,43 @@ using namespace llvm;
 
 #define AARCH64_SLS_HARDENING_NAME "AArch64 sls hardening pass"
 
+static const char SLSBLRNamePrefix[] = "__llvm_slsblr_thunk_";
+
 namespace {
 
-class AArch64SLSHardening : public MachineFunctionPass {
-public:
-  const TargetInstrInfo *TII;
-  const TargetRegisterInfo *TRI;
-  const AArch64Subtarget *ST;
+// Set of inserted thunks: bitmask with bits corresponding to
+// indexes in SLSBLRThunks array.
+typedef uint32_t ThunksSet;
 
-  static char ID;
-
-  AArch64SLSHardening() : MachineFunctionPass(ID) {
-initializeAArch64SLSHardeningPass(*PassRegistry::getPassRegistry());
+struct SLSBLRThunkInserter : ThunkInserter {

kbeyls wrote:

I'm not sure if `SLSBLRThunkInserter` is the most appropriate name for this 
class.
IIUC, this class will also harden Returns and BRs, (see method 
`hardenReturnsAndBRs`), which does not insert thunks.
If I understand this correctly, I think sticking with the original name of 
"AArch64SLSHardening" describes better what this class does?

https://github.com/llvm/llvm-project/pull/97472
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [llvm] [AArch64] Only create called thunks when hardening against SLS (PR #97472)

[Kristof Beyls via llvm-branch-commits]

@@ -36,38 +32,43 @@ using namespace llvm;
 
 #define AARCH64_SLS_HARDENING_NAME "AArch64 sls hardening pass"
 
+static const char SLSBLRNamePrefix[] = "__llvm_slsblr_thunk_";
+
 namespace {
 
-class AArch64SLSHardening : public MachineFunctionPass {
-public:
-  const TargetInstrInfo *TII;
-  const TargetRegisterInfo *TRI;
-  const AArch64Subtarget *ST;
+// Set of inserted thunks: bitmask with bits corresponding to
+// indexes in SLSBLRThunks array.
+typedef uint32_t ThunksSet;

kbeyls wrote:

I guess once support for BLRA* instruction will be added, the bitset may 
contain up to 29\*29-ish registers and this typedef will change to something 
different than a `uint32_t`?
I agree this can be done in the follow-on patch that will support BLRA* 
instructions.

https://github.com/llvm/llvm-project/pull/97472
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [llvm] [AArch64] Only create called thunks when hardening against SLS (PR #97472)

[Kristof Beyls via llvm-branch-commits]

@@ -46,13 +40,5 @@ body: |
 
 
 ...

-name:__llvm_slsblr_thunk_x8
-tracksRegLiveness: true
-body: |
-  bb.0.entry:
-liveins: $x8
 
-BR $x8

kbeyls wrote:

I think it is important to check that the body of the thunk inserted is as 
expected.
What is the motivation to remove that check, and only check that a thunk with 
the expected name was inserted, without checking its body?

https://github.com/llvm/llvm-project/pull/97472
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [llvm] [Support] Integrate SipHash.cpp into libSupport. (PR #94394)

[Kristof Beyls via llvm-branch-commits]

https://github.com/kbeyls approved this pull request.


https://github.com/llvm/llvm-project/pull/94394
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [llvm] [Support] Integrate SipHash.cpp into libSupport. (PR #94394)

[Kristof Beyls via llvm-branch-commits]

kbeyls wrote:

> [37c84b9](https://github.com/llvm/llvm-project/pull/94394/commits/37c84b9dce70f40db8a7c27b7de8232c4d10f78f)
>  shows what I had in mind, let me know what you all think. I added:
> 
> ```
> void getSipHash_2_4_64(ArrayRef In, const uint8_t ()[16],
>uint8_t ()[8]);
> 
> void getSipHash_2_4_128(ArrayRef In, const uint8_t ()[16],
> uint8_t ()[16]);
> ```
> 
> as the core interfaces, and mimicked the ref. test harness to reuse the same 
> test vectors. If this seems reasonable to yall I'm happy to extract the 
> vectors.h file from the ref. implementation into the "Import original 
> sources" PR – that's why I kept it open ;)

Thanks, that looks good to me.

https://github.com/llvm/llvm-project/pull/94394
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [llvm] [Support] Integrate SipHash.cpp into libSupport. (PR #94394)

[Kristof Beyls via llvm-branch-commits]

kbeyls wrote:

> Yes, this doesn't have tests by itself because there's no exposed interface. 
> It's certainly trivial to add one (which would allow using the reference test 
> vectors).
> 
> I don't have strong arguments either way, but I figured the conservative 
> option is to force hypothetical users to consider their use more seriously. 
> One might argue that's not how we usually treat libSupport, so I'm happy to 
> expose the raw function here.

I see some value in being able to test with the reference test vectors to be 
fully sure that the implementation really implements SipHash. But as I said 
above, I'm happy with merging this as is.

https://github.com/llvm/llvm-project/pull/94394
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [llvm] [Support] Integrate SipHash.cpp into libSupport. (PR #94394)

[Kristof Beyls via llvm-branch-commits]

https://github.com/kbeyls approved this pull request.


https://github.com/llvm/llvm-project/pull/94394
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [llvm] [Support] Integrate SipHash.cpp into libSupport. (PR #94394)

[Kristof Beyls via llvm-branch-commits]

kbeyls wrote:

I just checked if there indeed are big-endian bots which should pick up if a 
different hash gets produced on a big-endian system. I guess this bot (the only 
bot?) would pick it up: https://lab.llvm.org/buildbot/#/builders/231

I now also realize that there are no tests with this commit. I assume that 
later commits that test hash computation for a pointer authentication 
discriminator will implicitly test this. In the ideal world, it seems there 
should be a simple test, e.g. checking one 64 bit and one 128 bit hash as part 
of this commit?
I don't think not having the test should block landing this PR, but if it would 
be straightforward to add a test, then I think it is still worthwhile to do it 
as part of this PR.

https://github.com/llvm/llvm-project/pull/94394
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [llvm] [Support] Integrate SipHash.cpp into libSupport. (PR #94394)

[Kristof Beyls via llvm-branch-commits]

kbeyls wrote:

> So, regarding big-endian things. Original siphash is always "little-endian" 
> regardless of the host platform. On big endian hosts it essentially does byte 
> swap in the end. We do not have it here, so we will end with different hashes 
> on platforms with different endianness.
> 
> From the pauth perspective this is not a problem, as we do not do 
> cross-platform hash calculation and further comparison. The hash output 
> (discriminator value) is always compiled on compiler side and left as-is.
> 
> So, we can either keep the present code as-is. Or we can just sprinkle few 
> calls from `Endian.h` to do byteswap on BE platforms.

I was thinking that it is important that on both big and little endian 
platforms, the same hash is produced? Otherwise it becomes impossible to 
cross-compile from an other-endian host to an other-endian target? That 
basically would break ABI?
It would surface when combining libraries built on differently-endian 
platforms. Maybe this doesn't happen often in practice, but LLVM remains 
supported on big-endian platforms, so I would think it's important that those 
platforms can cross-compile correctly to other targets?

https://github.com/llvm/llvm-project/pull/94394
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [llvm] [Support] Integrate SipHash.cpp into libSupport. (PR #94394)

[Kristof Beyls via llvm-branch-commits]

kbeyls wrote:

> I'll also mention that I left the original variable naming but did re-format 
> the file, whitespace being more friendly to diffs, and this being nice and 
> tidily contained. If you or others have strong opinions, I'm happy to 
> recapitalize the names.

I don't have a strong opinion; I can see the argument both ways. Happy with it 
as is.

https://github.com/llvm/llvm-project/pull/94394
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [llvm] [Support] Integrate SipHash.cpp into libSupport. (PR #94394)

[Kristof Beyls via llvm-branch-commits]

@@ -1,25 +1,19 @@
-/*
-   SipHash reference C implementation
-
-   Copyright (c) 2012-2022 Jean-Philippe Aumasson
-   
-   Copyright (c) 2012-2014 Daniel J. Bernstein 
-
-   To the extent possible under law, the author(s) have dedicated all copyright
-   and related and neighboring rights to this software to the public domain
-   worldwide. This software is distributed without any warranty.
-
-   You should have received a copy of the CC0 Public Domain Dedication along
-   with
-   this software. If not, see
-   .
- */
+//===--- SipHash.cpp - An ABI-stable string hash 
--===//
+//
+// 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
+//
+//===--===//
 
 #include "siphash.h"
 #include 
 #include 
 #include 
 
+// Lightly adapted from the SipHash reference C implementation by
+// Jean-Philippe Aumasson and Daniel J. Bernstein.

kbeyls wrote:

It might be worthwhile to also add the link to the upstream repo in this 
comment: https://github.com/veorq/SipHash?

https://github.com/llvm/llvm-project/pull/94394
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [llvm] [Support] Integrate SipHash.cpp into libSupport. (PR #94394)

[Kristof Beyls via llvm-branch-commits]

@@ -58,21 +38,15 @@
 v2 = ROTL(v2, 32); 
\
   } while (0)
 
-/*
-Computes a SipHash value
-*in: pointer to input data (read-only)
-inlen: input data length in bytes (any size_t value)
-*k: pointer to the key data (read-only), must be 16 bytes
-*out: pointer to output data (write-only), outlen bytes must be allocated
-outlen: length of the output in bytes, must be 8 or 16
-*/
-int siphash(const void *in, const size_t inlen, const void *k, uint8_t *out,
-const size_t outlen) {
+template 
+static inline ResultTy siphash(const unsigned char *in, uint64_t inlen,
+   const unsigned char ()[16]) {
 
   const unsigned char *ni = (const unsigned char *)in;
   const unsigned char *kk = (const unsigned char *)k;
 
-  assert((outlen == 8) || (outlen == 16));

kbeyls wrote:

I guess that adding
```
const size_t outlen = sizeof(ResultTy);
```
above this might result in fewer local modification needed in the rest of this 
function implementation?
Not sure if it's worth it. It might make it somewhat easier to update the 
implementation to a later "upstream" version if that would ever be needed. But 
I guess that's it's unlikely we'd ever need to update the implementation to a 
later upstream version

https://github.com/llvm/llvm-project/pull/94394
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [llvm] [Support] Integrate SipHash.cpp into libSupport. (PR #94394)

[Kristof Beyls via llvm-branch-commits]

https://github.com/kbeyls requested changes to this pull request.

Do I understand correctly that "remove big-endian support" results in this code 
not running correctly on big-endian machines?
I don't recall the LLVM project claiming that it cannot run on big-endian 
machines.
If I understand this correctly, I would not remove the big-endian support.
(I think it also helps with keeping the source code closer to the upstream 
siphash version, which might have some benefits?)

https://github.com/llvm/llvm-project/pull/94394
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [llvm] [Support] Integrate SipHash.cpp into libSupport. (PR #94394)

[Kristof Beyls via llvm-branch-commits]

@@ -58,21 +38,15 @@
 v2 = ROTL(v2, 32); 
\
   } while (0)
 
-/*

kbeyls wrote:

It might be worthwhile to keep (an edited version of) this comment? It wasn't 
immediately obvious to me what the value is of removing it.

https://github.com/llvm/llvm-project/pull/94394
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [llvm] [Support] Integrate SipHash.cpp into libSupport. (PR #94394)

[Kristof Beyls via llvm-branch-commits]

@@ -58,21 +38,15 @@
 v2 = ROTL(v2, 32); 
\
   } while (0)
 
-/*
-Computes a SipHash value
-*in: pointer to input data (read-only)
-inlen: input data length in bytes (any size_t value)
-*k: pointer to the key data (read-only), must be 16 bytes
-*out: pointer to output data (write-only), outlen bytes must be allocated
-outlen: length of the output in bytes, must be 8 or 16
-*/
-int siphash(const void *in, const size_t inlen, const void *k, uint8_t *out,
-const size_t outlen) {
+template 
+static inline ResultTy siphash(const unsigned char *in, uint64_t inlen,

kbeyls wrote:

Rather than using "static inline", wouldn't putting the `siphash` function in 
an anonymous namespace be the more C++-way of not making this function 
available to other translation units?
I'm also not fully sure if the `inline` keyword makes a meaningful difference?
(I'm not an expert on this, just wondering)

https://github.com/llvm/llvm-project/pull/94394
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [llvm] [Support] Integrate SipHash.cpp into libSupport. (PR #94394)

[Kristof Beyls via llvm-branch-commits]

https://github.com/kbeyls edited https://github.com/llvm/llvm-project/pull/94394
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [clang] c816be2 - Add release note for aarch64-none-elf driver change.

[Kristof Beyls via llvm-branch-commits]

Author: Kristof Beyls
Date: 2022-01-26T09:13:22+01:00
New Revision: c816be2026af3641f9b648482c48dd1f18a73dd1

URL: 
https://github.com/llvm/llvm-project/commit/c816be2026af3641f9b648482c48dd1f18a73dd1
DIFF: 
https://github.com/llvm/llvm-project/commit/c816be2026af3641f9b648482c48dd1f18a73dd1.diff

LOG: Add release note for aarch64-none-elf driver change.

Added: 


Modified: 
clang/docs/ReleaseNotes.rst

Removed: 




diff  --git a/clang/docs/ReleaseNotes.rst b/clang/docs/ReleaseNotes.rst
index 2272d7197ac57..6a9b046a1427d 100644
--- a/clang/docs/ReleaseNotes.rst
+++ b/clang/docs/ReleaseNotes.rst
@@ -275,6 +275,9 @@ Arm and AArch64 Support in Clang
   architecture features, but will enable certain optimizations specific to
   Cortex-A57 CPUs and enable the use of a more accurate scheduling model.
 
+- The --aarch64-none-elf target now uses the BareMetal driver rather than the
+  GNU driver. Programs that depend on clang invoking GCC as the linker driver
+  should use GCC as the linker in the build system.
 
 Floating Point Support in Clang
 ---



___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [clang] 9c895ae - [ARM] Add clang command line support for -mharden-sls=

[Kristof Beyls via llvm-branch-commits]

Author: Kristof Beyls
Date: 2020-12-19T12:49:26Z
New Revision: 9c895aea118a2f50ca8413372363c3ff6ecc21bf

URL: 
https://github.com/llvm/llvm-project/commit/9c895aea118a2f50ca8413372363c3ff6ecc21bf
DIFF: 
https://github.com/llvm/llvm-project/commit/9c895aea118a2f50ca8413372363c3ff6ecc21bf.diff

LOG: [ARM] Add clang command line support for -mharden-sls=

The command line syntax is identical to the -mharden-sls= command line
syntax for AArch64 targets.

Differential Revision: https://reviews.llvm.org/D93221

Added: 
clang/test/Driver/sls-hardening-options.c

Modified: 
clang/include/clang/Basic/DiagnosticDriverKinds.td
clang/lib/Driver/ToolChains/Arch/ARM.cpp
clang/lib/Driver/ToolChains/Arch/ARM.h

Removed: 
clang/test/Driver/aarch64-sls-hardening-options.c



diff  --git a/clang/include/clang/Basic/DiagnosticDriverKinds.td 
b/clang/include/clang/Basic/DiagnosticDriverKinds.td
index c67cce099a28..e92a4bf1dac5 100644
--- a/clang/include/clang/Basic/DiagnosticDriverKinds.td
+++ b/clang/include/clang/Basic/DiagnosticDriverKinds.td
@@ -348,6 +348,8 @@ def err_invalid_branch_protection: Error <
   "invalid branch protection option '%0' in '%1'">;
 def err_invalid_sls_hardening : Error<
   "invalid sls hardening option '%0' in '%1'">;
+def err_sls_hardening_arm_not_supported : Error<
+  "-mharden-sls is only supported on armv7-a or later">;
 
 def note_drv_command_failed_diag_msg : Note<
   "diagnostic msg: %0">;

diff  --git a/clang/lib/Driver/ToolChains/Arch/ARM.cpp 
b/clang/lib/Driver/ToolChains/Arch/ARM.cpp
index 309a7298300f..ef590db1eecd 100644
--- a/clang/lib/Driver/ToolChains/Arch/ARM.cpp
+++ b/clang/lib/Driver/ToolChains/Arch/ARM.cpp
@@ -32,6 +32,12 @@ bool arm::isARMMProfile(const llvm::Triple ) {
   return llvm::ARM::parseArchProfile(Arch) == llvm::ARM::ProfileKind::M;
 }
 
+// True if A-profile.
+bool arm::isARMAProfile(const llvm::Triple ) {
+  llvm::StringRef Arch = Triple.getArchName();
+  return llvm::ARM::parseArchProfile(Arch) == llvm::ARM::ProfileKind::A;
+}
+
 // Get Arch/CPU from args.
 void arm::getARMArchCPUFromArgs(const ArgList , llvm::StringRef ,
 llvm::StringRef , bool FromAs) {
@@ -606,6 +612,45 @@ void arm::getARMTargetFeatures(const Driver , const 
llvm::Triple ,
 
   if (Args.hasArg(options::OPT_mno_neg_immediates))
 Features.push_back("+no-neg-immediates");
+
+  // Enable/disable straight line speculation hardening.
+  if (Arg *A = Args.getLastArg(options::OPT_mharden_sls_EQ)) {
+StringRef Scope = A->getValue();
+bool EnableRetBr = false;
+bool EnableBlr = false;
+if (Scope != "none" && Scope != "all") {
+  SmallVector Opts;
+  Scope.split(Opts, ",");
+  for (auto Opt : Opts) {
+Opt = Opt.trim();
+if (Opt == "retbr") {
+  EnableRetBr = true;
+  continue;
+}
+if (Opt == "blr") {
+  EnableBlr = true;
+  continue;
+}
+D.Diag(diag::err_invalid_sls_hardening)
+<< Scope << A->getAsString(Args);
+break;
+  }
+} else if (Scope == "all") {
+  EnableRetBr = true;
+  EnableBlr = true;
+}
+
+if (EnableRetBr || EnableBlr)
+  if (!(isARMAProfile(Triple) && getARMSubArchVersionNumber(Triple) >= 7))
+D.Diag(diag::err_sls_hardening_arm_not_supported)
+<< Scope << A->getAsString(Args);
+
+if (EnableRetBr)
+  Features.push_back("+harden-sls-retbr");
+if (EnableBlr)
+  Features.push_back("+harden-sls-blr");
+  }
+
 }
 
 const std::string arm::getARMArch(StringRef Arch, const llvm::Triple ) {

diff  --git a/clang/lib/Driver/ToolChains/Arch/ARM.h 
b/clang/lib/Driver/ToolChains/Arch/ARM.h
index 091c09b160ae..02d91cdaee13 100644
--- a/clang/lib/Driver/ToolChains/Arch/ARM.h
+++ b/clang/lib/Driver/ToolChains/Arch/ARM.h
@@ -63,6 +63,7 @@ void getARMTargetFeatures(const Driver , const llvm::Triple 
,
   std::vector , bool ForAS);
 int getARMSubArchVersionNumber(const llvm::Triple );
 bool isARMMProfile(const llvm::Triple );
+bool isARMAProfile(const llvm::Triple );
 
 } // end namespace arm
 } // end namespace tools

diff  --git a/clang/test/Driver/aarch64-sls-hardening-options.c 
b/clang/test/Driver/aarch64-sls-hardening-options.c
deleted file mode 100644
index 250007aa1254..
--- a/clang/test/Driver/aarch64-sls-hardening-options.c
+++ /dev/null
@@ -1,45 +0,0 @@
-// Check the -mharden-sls= option, which has a required argument to select
-// scope.
-// RUN: %clang -target aarch64--none-eabi -c %s -### 2>&1 | \
-// RUN: FileCheck %s --check-prefix=RETBR-OFF --check-prefix=BLR-OFF
-
-// RUN: %clang -target aarch64--none-eabi -c %s -### -mharden-sls=none 2>&1 | \
-// RUN: FileCheck %s --check-prefix=RETBR-OFF --check-prefix=BLR-OFF
-
-// RUN: %clang -target aarch64--none-eabi -c %s -### -mharden-sls=retbr 2>&1 | 
\
-// RUN: FileCheck %s 

[llvm-branch-commits] [llvm] df8ed39 - [ARM] harden-sls-blr: avoid r12 and lr in indirect calls.

[Kristof Beyls via llvm-branch-commits]

Author: Kristof Beyls
Date: 2020-12-19T12:39:59Z
New Revision: df8ed3928377edc6e9241a56680b694ffa9f4d6d

URL: 
https://github.com/llvm/llvm-project/commit/df8ed3928377edc6e9241a56680b694ffa9f4d6d
DIFF: 
https://github.com/llvm/llvm-project/commit/df8ed3928377edc6e9241a56680b694ffa9f4d6d.diff

LOG: [ARM] harden-sls-blr: avoid r12 and lr in indirect calls.

As a linker is allowed to clobber r12 on function calls, the code
transformation that hardens indirect calls is not correct in case a
linker does so.  Similarly, the transformation is not correct when
register lr is used.

This patch makes sure that r12 or lr are not used for indirect calls
when harden-sls-blr is enabled.

Differential Revision: https://reviews.llvm.org/D92469

Added: 


Modified: 
llvm/lib/Target/ARM/ARMBaseInstrInfo.cpp
llvm/lib/Target/ARM/ARMBaseInstrInfo.h
llvm/lib/Target/ARM/ARMCallLowering.cpp
llvm/lib/Target/ARM/ARMExpandPseudoInsts.cpp
llvm/lib/Target/ARM/ARMFastISel.cpp
llvm/lib/Target/ARM/ARMFeatures.h
llvm/lib/Target/ARM/ARMISelLowering.cpp
llvm/lib/Target/ARM/ARMInstrInfo.td
llvm/lib/Target/ARM/ARMInstrThumb.td
llvm/lib/Target/ARM/ARMPredicates.td
llvm/lib/Target/ARM/ARMRegisterBankInfo.cpp
llvm/lib/Target/ARM/ARMRegisterInfo.td
llvm/lib/Target/ARM/ARMSLSHardening.cpp
llvm/test/CodeGen/ARM/speculation-hardening-sls.ll

Removed: 




diff  --git a/llvm/lib/Target/ARM/ARMBaseInstrInfo.cpp 
b/llvm/lib/Target/ARM/ARMBaseInstrInfo.cpp
index 9a71b9264fcd..e77ed2c34bd3 100644
--- a/llvm/lib/Target/ARM/ARMBaseInstrInfo.cpp
+++ b/llvm/lib/Target/ARM/ARMBaseInstrInfo.cpp
@@ -5803,7 +5803,9 @@ outliner::OutlinedFunction 
ARMBaseInstrInfo::getOutliningCandidateInfo(
 NumBytesToCreateFrame = Costs.FrameTailCall;
 SetCandidateCallInfo(MachineOutlinerTailCall, Costs.CallTailCall);
   } else if (LastInstrOpcode == ARM::BL || LastInstrOpcode == ARM::BLX ||
- LastInstrOpcode == ARM::tBL || LastInstrOpcode == ARM::tBLXr ||
+ LastInstrOpcode == ARM::BLX_noip || LastInstrOpcode == ARM::tBL ||
+ LastInstrOpcode == ARM::tBLXr ||
+ LastInstrOpcode == ARM::tBLXr_noip ||
  LastInstrOpcode == ARM::tBLXi) {
 FrameID = MachineOutlinerThunk;
 NumBytesToCreateFrame = Costs.FrameThunk;
@@ -6051,7 +6053,8 @@ 
ARMBaseInstrInfo::getOutliningType(MachineBasicBlock::iterator ,
 // we don't get unexpected results with call pseudo-instructions.
 auto UnknownCallOutlineType = outliner::InstrType::Illegal;
 if (Opc == ARM::BL || Opc == ARM::tBL || Opc == ARM::BLX ||
-Opc == ARM::tBLXr || Opc == ARM::tBLXi)
+Opc == ARM::BLX_noip || Opc == ARM::tBLXr || Opc == ARM::tBLXr_noip ||
+Opc == ARM::tBLXi)
   UnknownCallOutlineType = outliner::InstrType::LegalTerminator;
 
 if (!Callee)
@@ -6343,3 +6346,19 @@ bool 
ARMBaseInstrInfo::isReallyTriviallyReMaterializable(const MachineInstr ,
   // spill/restore and VPT predication.
   return isVCTP() && !isPredicated(MI);
 }
+
+unsigned llvm::getBLXOpcode(const MachineFunction ) {
+  return (MF.getSubtarget().hardenSlsBlr()) ? ARM::BLX_noip
+  : ARM::BLX;
+}
+
+unsigned llvm::gettBLXrOpcode(const MachineFunction ) {
+  return (MF.getSubtarget().hardenSlsBlr()) ? ARM::tBLXr_noip
+  : ARM::tBLXr;
+}
+
+unsigned llvm::getBLXpredOpcode(const MachineFunction ) {
+  return (MF.getSubtarget().hardenSlsBlr()) ? ARM::BLX_pred_noip
+  : ARM::BLX_pred;
+}
+

diff  --git a/llvm/lib/Target/ARM/ARMBaseInstrInfo.h 
b/llvm/lib/Target/ARM/ARMBaseInstrInfo.h
index 47a2cf44f3a9..9b6572848ebe 100644
--- a/llvm/lib/Target/ARM/ARMBaseInstrInfo.h
+++ b/llvm/lib/Target/ARM/ARMBaseInstrInfo.h
@@ -640,13 +640,16 @@ static inline bool isIndirectCall(const MachineInstr ) 
{
   switch (Opc) {
 // indirect calls:
   case ARM::BLX:
+  case ARM::BLX_noip:
   case ARM::BLX_pred:
+  case ARM::BLX_pred_noip:
   case ARM::BX_CALL:
   case ARM::BMOVPCRX_CALL:
   case ARM::TCRETURNri:
   case ARM::TAILJMPr:
   case ARM::TAILJMPr4:
   case ARM::tBLXr:
+  case ARM::tBLXr_noip:
   case ARM::tBLXNSr:
   case ARM::tBLXNS_CALL:
   case ARM::tBX_CALL:
@@ -908,6 +911,10 @@ inline bool isGatherScatter(IntrinsicInst *IntInst) {
   return isGather(IntInst) || isScatter(IntInst);
 }
 
+unsigned getBLXOpcode(const MachineFunction );
+unsigned gettBLXrOpcode(const MachineFunction );
+unsigned getBLXpredOpcode(const MachineFunction );
+
 } // end namespace llvm
 
 #endif // LLVM_LIB_TARGET_ARM_ARMBASEINSTRINFO_H

diff  --git a/llvm/lib/Target/ARM/ARMCallLowering.cpp 
b/llvm/lib/Target/ARM/ARMCallLowering.cpp
index 2efc26203f58..0a38f737cb4b 100644
--- a/llvm/lib/Target/ARM/ARMCallLowering.cpp
+++ b/llvm/lib/Target/ARM/ARMCallLowering.cpp
@@ -480,15 

[llvm-branch-commits] [llvm] a4c1f51 - [ARM] Harden indirect calls against SLS

[Kristof Beyls via llvm-branch-commits]

Author: Kristof Beyls
Date: 2020-12-19T12:33:42Z
New Revision: a4c1f5160e6d1de9a9959ecbf329c2acf4f3ed31

URL: 
https://github.com/llvm/llvm-project/commit/a4c1f5160e6d1de9a9959ecbf329c2acf4f3ed31
DIFF: 
https://github.com/llvm/llvm-project/commit/a4c1f5160e6d1de9a9959ecbf329c2acf4f3ed31.diff

LOG: [ARM] Harden indirect calls against SLS

To make sure that no barrier gets placed on the architectural execution
path, each indirect call calling the function in register rN, it gets
transformed to a direct call to __llvm_slsblr_thunk_mode_rN.  mode is
either arm or thumb, depending on the mode of where the indirect call
happens.

The llvm_slsblr_thunk_mode_rN thunk contains:

bx rN


Therefore, the indirect call gets split into 2; one direct call and one
indirect jump.
This transformation results in not inserting a speculation barrier on
the architectural execution path.

The mitigation is off by default and can be enabled by the
harden-sls-blr subtarget feature.

As a linker is allowed to clobber r12 on function calls, the
above code transformation is not correct in case a linker does so.
Similarly, the transformation is not correct when register lr is used.
Avoiding r12/lr being used is done in a follow-on patch to make
reviewing this code easier.

Differential Revision: https://reviews.llvm.org/D92468

Added: 


Modified: 
llvm/lib/Target/ARM/ARM.h
llvm/lib/Target/ARM/ARM.td
llvm/lib/Target/ARM/ARMBaseInstrInfo.cpp
llvm/lib/Target/ARM/ARMBaseInstrInfo.h
llvm/lib/Target/ARM/ARMSLSHardening.cpp
llvm/lib/Target/ARM/ARMSubtarget.h
llvm/lib/Target/ARM/ARMTargetMachine.cpp
llvm/test/CodeGen/ARM/O3-pipeline.ll
llvm/test/CodeGen/ARM/speculation-hardening-sls.ll

Removed: 




diff  --git a/llvm/lib/Target/ARM/ARM.h b/llvm/lib/Target/ARM/ARM.h
index 51dfaaa96892..d8a4e4c31012 100644
--- a/llvm/lib/Target/ARM/ARM.h
+++ b/llvm/lib/Target/ARM/ARM.h
@@ -56,6 +56,7 @@ createARMInstructionSelector(const ARMBaseTargetMachine , 
const ARMSubtarget
  const ARMRegisterBankInfo );
 Pass *createMVEGatherScatterLoweringPass();
 FunctionPass *createARMSLSHardeningPass();
+FunctionPass *createARMIndirectThunks();
 
 void LowerARMMachineInstrToMCInst(const MachineInstr *MI, MCInst ,
   ARMAsmPrinter );

diff  --git a/llvm/lib/Target/ARM/ARM.td b/llvm/lib/Target/ARM/ARM.td
index 4d4ace51e13f..8111346c74f6 100644
--- a/llvm/lib/Target/ARM/ARM.td
+++ b/llvm/lib/Target/ARM/ARM.td
@@ -570,6 +570,10 @@ def FeatureHardenSlsRetBr : 
SubtargetFeature<"harden-sls-retbr",
   "HardenSlsRetBr", "true",
   "Harden against straight line speculation across RETurn and BranchRegister "
   "instructions">;
+def FeatureHardenSlsBlr : SubtargetFeature<"harden-sls-blr",
+  "HardenSlsBlr", "true",
+  "Harden against straight line speculation across indirect calls">;
+
 
 
 
//===--===//

diff  --git a/llvm/lib/Target/ARM/ARMBaseInstrInfo.cpp 
b/llvm/lib/Target/ARM/ARMBaseInstrInfo.cpp
index 1435bba776a3..9a71b9264fcd 100644
--- a/llvm/lib/Target/ARM/ARMBaseInstrInfo.cpp
+++ b/llvm/lib/Target/ARM/ARMBaseInstrInfo.cpp
@@ -691,6 +691,8 @@ bool ARMBaseInstrInfo::isPredicable(const MachineInstr ) 
const {
   const ARMSubtarget  = MF->getSubtarget();
   if (ST.hardenSlsRetBr() && isIndirectControlFlowNotComingBack(MI))
 return false;
+  if (ST.hardenSlsBlr() && isIndirectCall(MI))
+return false;
 
   if (AFI->isThumb2Function()) {
 if (getSubtarget().restrictIT())

diff  --git a/llvm/lib/Target/ARM/ARMBaseInstrInfo.h 
b/llvm/lib/Target/ARM/ARMBaseInstrInfo.h
index e4e71e4925b9..47a2cf44f3a9 100644
--- a/llvm/lib/Target/ARM/ARMBaseInstrInfo.h
+++ b/llvm/lib/Target/ARM/ARMBaseInstrInfo.h
@@ -635,6 +635,51 @@ bool isIndirectBranchOpcode(int Opc) {
   return Opc == ARM::BX || Opc == ARM::MOVPCRX || Opc == ARM::tBRIND;
 }
 
+static inline bool isIndirectCall(const MachineInstr ) {
+  int Opc = MI.getOpcode();
+  switch (Opc) {
+// indirect calls:
+  case ARM::BLX:
+  case ARM::BLX_pred:
+  case ARM::BX_CALL:
+  case ARM::BMOVPCRX_CALL:
+  case ARM::TCRETURNri:
+  case ARM::TAILJMPr:
+  case ARM::TAILJMPr4:
+  case ARM::tBLXr:
+  case ARM::tBLXNSr:
+  case ARM::tBLXNS_CALL:
+  case ARM::tBX_CALL:
+  case ARM::tTAILJMPr:
+assert(MI.isCall(MachineInstr::IgnoreBundle));
+return true;
+// direct calls:
+  case ARM::BL:
+  case ARM::BL_pred:
+  case ARM::BMOVPCB_CALL:
+  case ARM::BL_PUSHLR:
+  case ARM::BLXi:
+  case ARM::TCRETURNdi:
+  case ARM::TAILJMPd:
+  case ARM::SVC:
+  case ARM::HVC:
+  case ARM::TPsoft:
+  case ARM::tTAILJMPd:
+  case ARM::t2SMC:
+  case ARM::t2HVC:
+  case ARM::tBL:
+  case ARM::tBLXi:
+  case ARM::tBL_PUSHLR:
+  case ARM::tTAILJMPdND:
+  case ARM::tSVC:
+  case ARM::tTPsoft:
+assert(MI.isCall(MachineInstr::IgnoreBundle));
+return false;
+  }
+  

[llvm-branch-commits] [llvm] 320fd33 - [ARM] Implement harden-sls-retbr for Thumb mode

[Kristof Beyls via llvm-branch-commits]

Author: Kristof Beyls
Date: 2020-12-19T12:32:47Z
New Revision: 320fd3314e378ae6242a2dde97250a8a94d68e27

URL: 
https://github.com/llvm/llvm-project/commit/320fd3314e378ae6242a2dde97250a8a94d68e27
DIFF: 
https://github.com/llvm/llvm-project/commit/320fd3314e378ae6242a2dde97250a8a94d68e27.diff

LOG: [ARM] Implement harden-sls-retbr for Thumb mode

The only non-trivial consideration in this patch is that the formation
of TBB/TBH instructions, which is done in the constant island pass, does
not understand the speculation barriers inserted by the SLSHardening
pass. As such, when harden-sls-retbr is enabled for a function, the
formation of TBB/TBH instructions in the constant island pass is
disabled.

Differential Revision: https://reviews.llvm.org/D92396

Added: 


Modified: 
llvm/lib/Target/ARM/ARMAsmPrinter.cpp
llvm/lib/Target/ARM/ARMBaseInstrInfo.cpp
llvm/lib/Target/ARM/ARMBaseInstrInfo.h
llvm/lib/Target/ARM/ARMConstantIslandPass.cpp
llvm/lib/Target/ARM/ARMInstrThumb2.td
llvm/lib/Target/ARM/ARMSLSHardening.cpp
llvm/test/CodeGen/ARM/speculation-hardening-sls.ll

Removed: 




diff  --git a/llvm/lib/Target/ARM/ARMAsmPrinter.cpp 
b/llvm/lib/Target/ARM/ARMAsmPrinter.cpp
index 4cc85ad82d51..dd22e5dfe6e1 100644
--- a/llvm/lib/Target/ARM/ARMAsmPrinter.cpp
+++ b/llvm/lib/Target/ARM/ARMAsmPrinter.cpp
@@ -2192,6 +2192,22 @@ void ARMAsmPrinter::emitInstruction(const MachineInstr 
*MI) {
 EmitToStreamer(*OutStreamer, TmpInstISB);
 return;
   }
+  case ARM::t2SpeculationBarrierISBDSBEndBB: {
+// Print DSB SYS + ISB
+MCInst TmpInstDSB;
+TmpInstDSB.setOpcode(ARM::t2DSB);
+TmpInstDSB.addOperand(MCOperand::createImm(0xf));
+TmpInstDSB.addOperand(MCOperand::createImm(ARMCC::AL));
+TmpInstDSB.addOperand(MCOperand::createReg(0));
+EmitToStreamer(*OutStreamer, TmpInstDSB);
+MCInst TmpInstISB;
+TmpInstISB.setOpcode(ARM::t2ISB);
+TmpInstISB.addOperand(MCOperand::createImm(0xf));
+TmpInstISB.addOperand(MCOperand::createImm(ARMCC::AL));
+TmpInstISB.addOperand(MCOperand::createReg(0));
+EmitToStreamer(*OutStreamer, TmpInstISB);
+return;
+  }
   case ARM::SpeculationBarrierSBEndBB: {
 // Print SB
 MCInst TmpInstSB;
@@ -2199,6 +2215,13 @@ void ARMAsmPrinter::emitInstruction(const MachineInstr 
*MI) {
 EmitToStreamer(*OutStreamer, TmpInstSB);
 return;
   }
+  case ARM::t2SpeculationBarrierSBEndBB: {
+// Print SB
+MCInst TmpInstSB;
+TmpInstSB.setOpcode(ARM::t2SB);
+EmitToStreamer(*OutStreamer, TmpInstSB);
+return;
+  }
   }
 
   MCInst TmpInst;

diff  --git a/llvm/lib/Target/ARM/ARMBaseInstrInfo.cpp 
b/llvm/lib/Target/ARM/ARMBaseInstrInfo.cpp
index 7068da5eb004..1435bba776a3 100644
--- a/llvm/lib/Target/ARM/ARMBaseInstrInfo.cpp
+++ b/llvm/lib/Target/ARM/ARMBaseInstrInfo.cpp
@@ -775,9 +775,11 @@ unsigned ARMBaseInstrInfo::getInstSizeInBytes(const 
MachineInstr ) const {
 return Size;
   }
   case ARM::SpeculationBarrierISBDSBEndBB:
+  case ARM::t2SpeculationBarrierISBDSBEndBB:
 // This gets lowered to 2 4-byte instructions.
 return 8;
   case ARM::SpeculationBarrierSBEndBB:
+  case ARM::t2SpeculationBarrierSBEndBB:
 // This gets lowered to 1 4-byte instructions.
 return 4;
   }

diff  --git a/llvm/lib/Target/ARM/ARMBaseInstrInfo.h 
b/llvm/lib/Target/ARM/ARMBaseInstrInfo.h
index 51a4b44eae1d..e4e71e4925b9 100644
--- a/llvm/lib/Target/ARM/ARMBaseInstrInfo.h
+++ b/llvm/lib/Target/ARM/ARMBaseInstrInfo.h
@@ -643,7 +643,9 @@ static inline bool isIndirectControlFlowNotComingBack(const 
MachineInstr ) {
 
 static inline bool isSpeculationBarrierEndBBOpcode(int Opc) {
   return Opc == ARM::SpeculationBarrierISBDSBEndBB ||
- Opc == ARM::SpeculationBarrierSBEndBB;
+ Opc == ARM::SpeculationBarrierSBEndBB ||
+ Opc == ARM::t2SpeculationBarrierISBDSBEndBB ||
+ Opc == ARM::t2SpeculationBarrierSBEndBB;
 }
 
 static inline bool isPopOpcode(int Opc) {

diff  --git a/llvm/lib/Target/ARM/ARMConstantIslandPass.cpp 
b/llvm/lib/Target/ARM/ARMConstantIslandPass.cpp
index 77839710e03e..da7bf6170255 100644
--- a/llvm/lib/Target/ARM/ARMConstantIslandPass.cpp
+++ b/llvm/lib/Target/ARM/ARMConstantIslandPass.cpp
@@ -359,6 +359,10 @@ bool 
ARMConstantIslands::runOnMachineFunction(MachineFunction ) {
   isThumb2 = AFI->isThumb2Function();
 
   bool GenerateTBB = isThumb2 || (isThumb1 && SynthesizeThumb1TBB);
+  // TBB generation code in this constant island pass has not been adapted to
+  // deal with speculation barriers.
+  if (STI->hardenSlsRetBr())
+GenerateTBB = false;
 
   // Renumber all of the machine basic blocks in the function, guaranteeing 
that
   // the numbers agree with the position of the block in the function.

diff  --git a/llvm/lib/Target/ARM/ARMInstrThumb2.td 
b/llvm/lib/Target/ARM/ARMInstrThumb2.td
index 52da88dab632..f83807d27f88 100644
--- a/llvm/lib/Target/ARM/ARMInstrThumb2.td

[llvm-branch-commits] [llvm] 195f442 - [ARM] Implement harden-sls-retbr for ARM mode

[Kristof Beyls via llvm-branch-commits]

Author: Kristof Beyls
Date: 2020-12-19T11:42:39Z
New Revision: 195f44278c4361a4a32377a98a1e3a15203d3647

URL: 
https://github.com/llvm/llvm-project/commit/195f44278c4361a4a32377a98a1e3a15203d3647
DIFF: 
https://github.com/llvm/llvm-project/commit/195f44278c4361a4a32377a98a1e3a15203d3647.diff

LOG: [ARM] Implement harden-sls-retbr for ARM mode

Some processors may speculatively execute the instructions immediately
following indirect control flow, such as returns, indirect jumps and
indirect function calls.

To avoid a potential miss-speculatively executed gadget after these
instructions leaking secrets through side channels, this pass places a
speculation barrier immediately after every indirect control flow where
control flow doesn't return to the next instruction, such as returns and
indirect jumps, but not indirect function calls.

Hardening of indirect function calls will be done in a later,
independent patch.

This patch is implementing the same functionality as the AArch64 counter
part implemented in https://reviews.llvm.org/D81400.
For AArch64, returns and indirect jumps only occur on RET and BR
instructions and hence the function attribute to control the hardening
is called "harden-sls-retbr" there. On AArch32, there is a much wider
variety of instructions that can trigger an indirect unconditional
control flow change.  I've decided to stick with the name
"harden-sls-retbr" as introduced for the corresponding AArch64
mitigation.

This patch implements this for ARM mode. A future patch will extend this
to also support Thumb mode.

The inserted barriers are never on the correct, architectural execution
path, and therefore performance overhead of this is expected to be low.
To ensure these barriers are never on an architecturally executed path,
when the harden-sls-retbr function attribute is present, indirect
control flow is never conditionalized/predicated.

On targets that implement that Armv8.0-SB Speculation Barrier extension,
a single SB instruction is emitted that acts as a speculation barrier.
On other targets, a DSB SYS followed by a ISB is emitted to act as a
speculation barrier.

These speculation barriers are implemented as pseudo instructions to
avoid later passes to analyze them and potentially remove them.

The mitigation is off by default and can be enabled by the
harden-sls-retbr subtarget feature.

Differential Revision: https://reviews.llvm.org/D92395

Added: 
llvm/lib/Target/ARM/ARMSLSHardening.cpp
llvm/test/CodeGen/ARM/speculation-hardening-sls.ll

Modified: 
llvm/lib/Target/ARM/ARM.h
llvm/lib/Target/ARM/ARM.td
llvm/lib/Target/ARM/ARMAsmPrinter.cpp
llvm/lib/Target/ARM/ARMBaseInstrInfo.cpp
llvm/lib/Target/ARM/ARMBaseInstrInfo.h
llvm/lib/Target/ARM/ARMConstantIslandPass.cpp
llvm/lib/Target/ARM/ARMInstrInfo.td
llvm/lib/Target/ARM/ARMSubtarget.h
llvm/lib/Target/ARM/ARMTargetMachine.cpp
llvm/lib/Target/ARM/CMakeLists.txt
llvm/test/CodeGen/ARM/O3-pipeline.ll

Removed: 




diff  --git a/llvm/lib/Target/ARM/ARM.h b/llvm/lib/Target/ARM/ARM.h
index 7398968bb24a..51dfaaa96892 100644
--- a/llvm/lib/Target/ARM/ARM.h
+++ b/llvm/lib/Target/ARM/ARM.h
@@ -55,6 +55,7 @@ InstructionSelector *
 createARMInstructionSelector(const ARMBaseTargetMachine , const 
ARMSubtarget ,
  const ARMRegisterBankInfo );
 Pass *createMVEGatherScatterLoweringPass();
+FunctionPass *createARMSLSHardeningPass();
 
 void LowerARMMachineInstrToMCInst(const MachineInstr *MI, MCInst ,
   ARMAsmPrinter );
@@ -71,6 +72,7 @@ void initializeMVEVPTOptimisationsPass(PassRegistry &);
 void initializeARMLowOverheadLoopsPass(PassRegistry &);
 void initializeMVETailPredicationPass(PassRegistry &);
 void initializeMVEGatherScatterLoweringPass(PassRegistry &);
+void initializeARMSLSHardeningPass(PassRegistry &);
 
 } // end namespace llvm
 

diff  --git a/llvm/lib/Target/ARM/ARM.td b/llvm/lib/Target/ARM/ARM.td
index 3fa65289744e..4d4ace51e13f 100644
--- a/llvm/lib/Target/ARM/ARM.td
+++ b/llvm/lib/Target/ARM/ARM.td
@@ -562,6 +562,16 @@ foreach i = {0-7} in
   "Coprocessor "#i#" ISA is CDEv1",
   [HasCDEOps]>;
 
+//===--===//
+// Control codegen mitigation against Straight Line Speculation vulnerability.
+//===--===//
+
+def FeatureHardenSlsRetBr : SubtargetFeature<"harden-sls-retbr",
+  "HardenSlsRetBr", "true",
+  "Harden against straight line speculation across RETurn and BranchRegister "
+  "instructions">;
+
+
 
//===--===//
 // ARM Processor subtarget features.
 //

diff  --git a/llvm/lib/Target/ARM/ARMAsmPrinter.cpp 

[llvm-branch-commits] [llvm] 424fdbc - collect_and_build_with_pgo.py: adapt to monorepo

[Kristof Beyls via llvm-branch-commits]

Author: Kristof Beyls
Date: 2020-12-01T09:16:12+01:00
New Revision: 424fdbc3dedadf882fda107aa5638b39e7036c4d

URL: 
https://github.com/llvm/llvm-project/commit/424fdbc3dedadf882fda107aa5638b39e7036c4d
DIFF: 
https://github.com/llvm/llvm-project/commit/424fdbc3dedadf882fda107aa5638b39e7036c4d.diff

LOG: collect_and_build_with_pgo.py: adapt to monorepo

Differential Revision: https://reviews.llvm.org/D92328

Added: 


Modified: 
llvm/utils/collect_and_build_with_pgo.py

Removed: 




diff  --git a/llvm/utils/collect_and_build_with_pgo.py 
b/llvm/utils/collect_and_build_with_pgo.py
index 5a8686a88b4f..e9f82617f4e9 100755
--- a/llvm/utils/collect_and_build_with_pgo.py
+++ b/llvm/utils/collect_and_build_with_pgo.py
@@ -146,9 +146,9 @@ def output_subdir(self, name):
 
 def has_llvm_subproject(self, name):
 if name == 'compiler-rt':
-subdir = 'projects/compiler-rt'
+subdir = '../compiler-rt'
 elif name == 'clang':
-subdir = 'tools/clang'
+subdir = '../clang'
 else:
 raise ValueError('Unknown subproject: %s' % name)
 
@@ -161,9 +161,8 @@ def run_command(self,
 cwd=None,
 check=False,
 silent_unless_error=False):
-cmd_str = ' '.join(shlex.quote(s) for s in cmd)
 print(
-'Running `%s` in %s' % (cmd_str, shlex.quote(cwd or os.getcwd(
+'Running `%s` in %s' % (cmd, shlex.quote(cwd or os.getcwd(
 
 if self.dry_run:
 return
@@ -372,7 +371,8 @@ def _parse_args():
 else:
 output_dir = os.path.abspath(args.out_dir)
 
-extra_args = {'CMAKE_BUILD_TYPE': 'Release'}
+extra_args = {'CMAKE_BUILD_TYPE': 'Release',
+  'LLVM_ENABLE_PROJECTS': 'clang;compiler-rt;lld'}
 for arg in args.cmake_extra_arg:
 if arg.startswith('-D'):
 arg = arg[2:]



___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [llvm] d98e4c0 - Add a few more release notes for ARM and AArch64.

[Kristof Beyls via llvm-branch-commits]

Author: Kristof Beyls
Date: 2020-08-31T14:10:54+02:00
New Revision: d98e4c0d9a3585e2302c717beea9b9d03df9663a

URL: 
https://github.com/llvm/llvm-project/commit/d98e4c0d9a3585e2302c717beea9b9d03df9663a
DIFF: 
https://github.com/llvm/llvm-project/commit/d98e4c0d9a3585e2302c717beea9b9d03df9663a.diff

LOG: Add a few more release notes for ARM and AArch64.

Added: 


Modified: 
llvm/docs/ReleaseNotes.rst

Removed: 




diff  --git a/llvm/docs/ReleaseNotes.rst b/llvm/docs/ReleaseNotes.rst
index c7ca861dbc34..8171f9d990c9 100644
--- a/llvm/docs/ReleaseNotes.rst
+++ b/llvm/docs/ReleaseNotes.rst
@@ -119,11 +119,26 @@ Changes to the AArch64 Backend
   ``00bet5``). For more information, see the ``clang`` 11 release
   notes.
 
+* Added support for Armv8.6-A:
+
+  Assembly support for the following extensions:
+  - Enhanced Counter Virtualization (ARMv8.6-ECV).
+  - Fine Grained Traps (ARMv8.6-FGT).
+  - Activity Monitors virtualization (ARMv8.6-AMU).
+  - Data gathering hint (ARMv8.0-DGH).
+
+  Assembly and intrinsics support for the Armv8.6-A Matrix Multiply extension
+  for Neon and SVE vectors.
+
+  Support for the ARMv8.2-BF16 BFloat16 extension. This includes a new C-level
+  storage-only `__bf16` type, a `BFloat` IR type, a `bf16` MVT, and assembly
+  and intrinsics support.
+
+* Added support for Cortex-A34, Cortex-A77, Cortex-A78 and Cortex-X1 cores.
+
 Changes to the ARM Backend
 --
 
-During this release ...
-
 * Implemented C-language intrinsics for the full Arm v8.1-M MVE instruction
   set.  now supports the complete API defined in the Arm C
   Language Extensions.
@@ -139,6 +154,19 @@ During this release ...
   default may wish to specify ``-fno-omit-frame-pointer`` to get the old
   behavior. This improves compatibility with GCC.
 
+* Added support for Armv8.6-A:
+
+  Assembly and intrinsics support for the Armv8.6-A Matrix Multiply extension
+  for Neon vectors.
+
+  Support for the ARMv8.2-AA32BF16 BFloat16 extension. This includes a new
+  C-level storage-only `__bf16` type, a `BFloat` IR type, a `bf16` MVT, and
+  assembly and intrinsics support.
+
+* Added support for CMSE.
+
+* Added support for Cortex-M55, Cortex-A77, Cortex-A78 and Cortex-X1 cores.
+
 Changes to the MIPS Target
 --
 



___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits