[PATCH] D90426: hwasan: Support for outlined checks in the Linux kernel.

Mitch Phillips via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Thu Oct 29 17:36:08 PDT 2020


hctim added inline comments.


================
Comment at: llvm/include/llvm/Transforms/Instrumentation/HWAddressSanitizer.h:40
 
+namespace HWASanAccessInfo {
+
----------------
why not `enum HWASanAccessInfo { ...`?


================
Comment at: llvm/lib/Target/AArch64/AArch64AsmPrinter.cpp:396
+    if (HasMatchAllTag) {
+      OutStreamer->emitInstruction(MCInstBuilder(AArch64::UBFMXri)
+                                       .addReg(AArch64::X16)
----------------
IIUC, this is being optimised to

```
lsr x16, x1, #56
cmp x16, MatchAllTag
b.eq .ret
```

and this seems clearer to me. Is it possible to update the codegen here to be the same?


================
Comment at: llvm/lib/Target/AArch64/AArch64AsmPrinter.cpp:513
+      OutStreamer->emitInstruction(
+          MCInstBuilder(AArch64::B).addExpr(HwasanTagMismatchRef), *STI);
+    } else {
----------------
`B` instead of `BR` implies that the kernel will never return from `__hwasan_tag_mismatch` (which is still reachable as it looks like it's still possible for the kernel to compile without short granules). Does this assumption always hold?


================
Comment at: llvm/lib/Transforms/Instrumentation/HWAddressSanitizer.cpp:796
           FunctionType::get(IRB.getVoidTy(), {PtrLong->getType()}, false),
-          "int3\nnopl " + itostr(0x40 + AccessInfo) + "(%rax)",
+          "int3\nnopl " + itostr(0x40 + (AccessInfo & 0xffff)) + "(%rax)",
           "{rdi}",
----------------
can we declare this as a const `kAccessInfoRuntimeMask` (and elsewhere)?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D90426/new/

https://reviews.llvm.org/D90426



More information about the llvm-commits mailing list