Re: [PATCH v12 20/25] kasan, arm64: add brk handler for inline instrumentation

On Thu, Dec 06, 2018 at 11:31:43AM +0100, Andrey Konovalov wrote:

On Thu, Nov 29, 2018 at 7:01 PM Will Deacon [off-list ref] wrote:

quoted

On Tue, Nov 27, 2018 at 05:55:38PM +0100, Andrey Konovalov wrote:

quoted

Tag-based KASAN inline instrumentation mode (which embeds checks of shadow
memory into the generated code, instead of inserting a callback) generates
a brk instruction when a tag mismatch is detected.

This commit adds a tag-based KASAN specific brk handler, that decodes the
immediate value passed to the brk instructions (to extract information
about the memory access that triggered the mismatch), reads the register
values (x0 contains the guilty address) and reports the bug.

Reviewed-by: Andrey Ryabinin <redacted>
Reviewed-by: Dmitry Vyukov <dvyukov@google.com>
Signed-off-by: Andrey Konovalov <redacted>
---
 arch/arm64/include/asm/brk-imm.h |  2 +
 arch/arm64/kernel/traps.c        | 68 +++++++++++++++++++++++++++++++-
 include/linux/kasan.h            |  3 ++
 3 files changed, 71 insertions(+), 2 deletions(-)

diff --git a/arch/arm64/include/asm/brk-imm.h b/arch/arm64/include/asm/brk-imm.h
index ed693c5bcec0..2945fe6cd863 100644
--- a/arch/arm64/include/asm/brk-imm.h
+++ b/arch/arm64/include/asm/brk-imm.h

@@ -16,10 +16,12 @@
  * 0x400: for dynamic BRK instruction
  * 0x401: for compile time BRK instruction
  * 0x800: kernel-mode BUG() and WARN() traps
+ * 0x9xx: tag-based KASAN trap (allowed values 0x900 - 0x9ff)
  */
 #define FAULT_BRK_IMM                        0x100
 #define KGDB_DYN_DBG_BRK_IMM         0x400
 #define KGDB_COMPILED_DBG_BRK_IMM    0x401
 #define BUG_BRK_IMM                  0x800
+#define KASAN_BRK_IMM                        0x900

 #endif

diff --git a/arch/arm64/kernel/traps.c b/arch/arm64/kernel/traps.c
index 5f4d9acb32f5..04bdc53716ef 100644
--- a/arch/arm64/kernel/traps.c
+++ b/arch/arm64/kernel/traps.c

@@ -35,6 +35,7 @@
 #include <linux/sizes.h>
 #include <linux/syscalls.h>
 #include <linux/mm_types.h>
+#include <linux/kasan.h>

 #include <asm/atomic.h>
 #include <asm/bug.h>

@@ -284,10 +285,14 @@ void arm64_notify_die(const char *str, struct pt_regs *regs,
      }
 }

-void arm64_skip_faulting_instruction(struct pt_regs *regs, unsigned long size)
+void __arm64_skip_faulting_instruction(struct pt_regs *regs, unsigned long size)
 {
      regs->pc += size;
+}

+void arm64_skip_faulting_instruction(struct pt_regs *regs, unsigned long size)
+{
+     __arm64_skip_faulting_instruction(regs, size);
      /*
       * If we were single stepping, we want to get the step exception after
       * we return from the trap.

@@ -959,7 +964,7 @@ static int bug_handler(struct pt_regs *regs, unsigned int esr)
      }

      /* If thread survives, skip over the BUG instruction and continue: */
-     arm64_skip_faulting_instruction(regs, AARCH64_INSN_SIZE);
+     __arm64_skip_faulting_instruction(regs, AARCH64_INSN_SIZE);

Why do you want to avoid the single-step logic here? Given that we're
skipping over the brk instruction, why wouldn't you want that to trigger
a step exception if single-step is enabled?

I was asked to do that, see the discussion here:

https://www.spinics.net/lists/linux-mm/msg146575.html
https://www.spinics.net/lists/linux-mm/msg148215.html
https://www.spinics.net/lists/linux-mm/msg148367.html

Aha, but we subsequently fixed the underlying problem in commit
9478f1927e6e ("arm64: only advance singlestep for user instruction traps").
You were on cc, but I appreciate it's not clear that it was related to this.

Anyway, you can just call arm64_skip_faulting_instruction() as you were
doing and there's no need for this refactoring.

Please could you spin a new version so that akpm can replace the one which
he has queued?

Thanks,

Will

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel