| Message ID | f5e73b5ead3355932ad8b5fc96b141c3f5b8c16c.1535462971.git.andreyknvl@google.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | khwasan: kernel hardware assisted address sanitizer | expand |
On Wed, Aug 29, 2018 at 1:35 PM, Andrey Konovalov <andreyknvl@google.com> wrote: > KHWASAN 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 add a KHWASAN 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. > > Signed-off-by: Andrey Konovalov <andreyknvl@google.com> > --- > arch/arm64/include/asm/brk-imm.h | 2 + > arch/arm64/kernel/traps.c | 69 +++++++++++++++++++++++++++++++- > 2 files changed, 69 insertions(+), 2 deletions(-) > > diff --git a/arch/arm64/include/asm/brk-imm.h b/arch/arm64/include/asm/brk-imm.h > index ed693c5bcec0..e4a7013321dc 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: KHWASAN 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 KHWASAN_BRK_IMM 0x900 > > #endif > diff --git a/arch/arm64/kernel/traps.c b/arch/arm64/kernel/traps.c > index 039e9ff379cc..fd70347d1ce7 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> > @@ -269,10 +270,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. > @@ -775,7 +780,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); > return DBG_HOOK_HANDLED; > } > > @@ -785,6 +790,59 @@ static struct break_hook bug_break_hook = { > .fn = bug_handler, > }; > > +#ifdef CONFIG_KASAN_HW > + > +#define KHWASAN_ESR_RECOVER 0x20 > +#define KHWASAN_ESR_WRITE 0x10 > +#define KHWASAN_ESR_SIZE_MASK 0x0f > +#define KHWASAN_ESR_SIZE(esr) (1 << ((esr) & KHWASAN_ESR_SIZE_MASK)) > + > +static int khwasan_handler(struct pt_regs *regs, unsigned int esr) > +{ > + bool recover = esr & KHWASAN_ESR_RECOVER; > + bool write = esr & KHWASAN_ESR_WRITE; > + size_t size = KHWASAN_ESR_SIZE(esr); > + u64 addr = regs->regs[0]; > + u64 pc = regs->pc; > + > + if (user_mode(regs)) > + return DBG_HOOK_ERROR; > + > + kasan_report(addr, size, write, pc); > + > + /* > + * The instrumentation allows to control whether we can proceed after > + * a crash was detected. This is done by passing the -recover flag to > + * the compiler. Disabling recovery allows to generate more compact > + * code. > + * > + * Unfortunately disabling recovery doesn't work for the kernel right > + * now. KHWASAN reporting is disabled in some contexts (for example when > + * the allocator accesses slab object metadata; same is true for KASAN; > + * this is controlled by current->kasan_depth). All these accesses are > + * detected by the tool, even though the reports for them are not > + * printed. I am not following this part. Slab accesses metadata. OK. This is detected as bad access. OK. Report is not printed. OK. We skip BRK and resume execution. What is the problem? > + * > + * This is something that might be fixed at some point in the future. > + */ > + if (!recover) > + die("Oops - KHWASAN", regs, 0); > + > + /* If thread survives, skip over the brk instruction and continue: */ > + __arm64_skip_faulting_instruction(regs, AARCH64_INSN_SIZE); > + return DBG_HOOK_HANDLED; > +} > + > +#define KHWASAN_ESR_VAL (0xf2000000 | KHWASAN_BRK_IMM) > +#define KHWASAN_ESR_MASK 0xffffff00 > + > +static struct break_hook khwasan_break_hook = { > + .esr_val = KHWASAN_ESR_VAL, > + .esr_mask = KHWASAN_ESR_MASK, > + .fn = khwasan_handler, > +}; > +#endif > + > /* > * Initial handler for AArch64 BRK exceptions > * This handler only used until debug_traps_init(). > @@ -792,6 +850,10 @@ static struct break_hook bug_break_hook = { > int __init early_brk64(unsigned long addr, unsigned int esr, > struct pt_regs *regs) > { > +#ifdef CONFIG_KASAN_HW > + if ((esr & KHWASAN_ESR_MASK) == KHWASAN_ESR_VAL) > + return khwasan_handler(regs, esr) != DBG_HOOK_HANDLED; > +#endif > return bug_handler(regs, esr) != DBG_HOOK_HANDLED; > } > > @@ -799,4 +861,7 @@ int __init early_brk64(unsigned long addr, unsigned int esr, > void __init trap_init(void) > { > register_break_hook(&bug_break_hook); > +#ifdef CONFIG_KASAN_HW > + register_break_hook(&khwasan_break_hook); > +#endif > } > -- > 2.19.0.rc0.228.g281dcd1b4d0-goog >
On Wed, Aug 29, 2018 at 1:35 PM, Andrey Konovalov <andreyknvl@google.com> wrote: > KHWASAN 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 add a KHWASAN 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. > > Signed-off-by: Andrey Konovalov <andreyknvl@google.com> > --- > arch/arm64/include/asm/brk-imm.h | 2 + > arch/arm64/kernel/traps.c | 69 +++++++++++++++++++++++++++++++- > 2 files changed, 69 insertions(+), 2 deletions(-) > > diff --git a/arch/arm64/include/asm/brk-imm.h b/arch/arm64/include/asm/brk-imm.h > index ed693c5bcec0..e4a7013321dc 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: KHWASAN 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 KHWASAN_BRK_IMM 0x900 > > #endif > diff --git a/arch/arm64/kernel/traps.c b/arch/arm64/kernel/traps.c > index 039e9ff379cc..fd70347d1ce7 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> > @@ -269,10 +270,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. > @@ -775,7 +780,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); > return DBG_HOOK_HANDLED; > } > > @@ -785,6 +790,59 @@ static struct break_hook bug_break_hook = { > .fn = bug_handler, > }; > > +#ifdef CONFIG_KASAN_HW > + > +#define KHWASAN_ESR_RECOVER 0x20 > +#define KHWASAN_ESR_WRITE 0x10 > +#define KHWASAN_ESR_SIZE_MASK 0x0f > +#define KHWASAN_ESR_SIZE(esr) (1 << ((esr) & KHWASAN_ESR_SIZE_MASK)) > + > +static int khwasan_handler(struct pt_regs *regs, unsigned int esr) > +{ > + bool recover = esr & KHWASAN_ESR_RECOVER; > + bool write = esr & KHWASAN_ESR_WRITE; > + size_t size = KHWASAN_ESR_SIZE(esr); > + u64 addr = regs->regs[0]; > + u64 pc = regs->pc; > + > + if (user_mode(regs)) > + return DBG_HOOK_ERROR; > + > + kasan_report(addr, size, write, pc); > + > + /* > + * The instrumentation allows to control whether we can proceed after > + * a crash was detected. This is done by passing the -recover flag to > + * the compiler. Disabling recovery allows to generate more compact > + * code. > + * > + * Unfortunately disabling recovery doesn't work for the kernel right > + * now. KHWASAN reporting is disabled in some contexts (for example when > + * the allocator accesses slab object metadata; same is true for KASAN; > + * this is controlled by current->kasan_depth). All these accesses are > + * detected by the tool, even though the reports for them are not > + * printed. > + * > + * This is something that might be fixed at some point in the future. > + */ > + if (!recover) > + die("Oops - KHWASAN", regs, 0); Why die and not panic? Die seems to be much less used function, and it calls panic anyway, and we call panic in kasan_report if panic_on_warn is set. > + /* If thread survives, skip over the brk instruction and continue: */ > + __arm64_skip_faulting_instruction(regs, AARCH64_INSN_SIZE); > + return DBG_HOOK_HANDLED; > +} > + > +#define KHWASAN_ESR_VAL (0xf2000000 | KHWASAN_BRK_IMM) > +#define KHWASAN_ESR_MASK 0xffffff00 > + > +static struct break_hook khwasan_break_hook = { > + .esr_val = KHWASAN_ESR_VAL, > + .esr_mask = KHWASAN_ESR_MASK, > + .fn = khwasan_handler, > +}; > +#endif > + > /* > * Initial handler for AArch64 BRK exceptions > * This handler only used until debug_traps_init(). > @@ -792,6 +850,10 @@ static struct break_hook bug_break_hook = { > int __init early_brk64(unsigned long addr, unsigned int esr, > struct pt_regs *regs) > { > +#ifdef CONFIG_KASAN_HW > + if ((esr & KHWASAN_ESR_MASK) == KHWASAN_ESR_VAL) > + return khwasan_handler(regs, esr) != DBG_HOOK_HANDLED; > +#endif > return bug_handler(regs, esr) != DBG_HOOK_HANDLED; > } > > @@ -799,4 +861,7 @@ int __init early_brk64(unsigned long addr, unsigned int esr, > void __init trap_init(void) > { > register_break_hook(&bug_break_hook); > +#ifdef CONFIG_KASAN_HW > + register_break_hook(&khwasan_break_hook); > +#endif > } > -- > 2.19.0.rc0.228.g281dcd1b4d0-goog >
On Wed, Sep 12, 2018 at 7:16 PM Dmitry Vyukov <dvyukov@google.com> wrote: > On Wed, Aug 29, 2018 at 1:35 PM, Andrey Konovalov <andreyknvl@google.com> wrote: [...] > > +static int khwasan_handler(struct pt_regs *regs, unsigned int esr) > > +{ > > + bool recover = esr & KHWASAN_ESR_RECOVER; > > + bool write = esr & KHWASAN_ESR_WRITE; > > + size_t size = KHWASAN_ESR_SIZE(esr); > > + u64 addr = regs->regs[0]; > > + u64 pc = regs->pc; > > + > > + if (user_mode(regs)) > > + return DBG_HOOK_ERROR; > > + > > + kasan_report(addr, size, write, pc); > > + > > + /* > > + * The instrumentation allows to control whether we can proceed after > > + * a crash was detected. This is done by passing the -recover flag to > > + * the compiler. Disabling recovery allows to generate more compact > > + * code. > > + * > > + * Unfortunately disabling recovery doesn't work for the kernel right > > + * now. KHWASAN reporting is disabled in some contexts (for example when > > + * the allocator accesses slab object metadata; same is true for KASAN; > > + * this is controlled by current->kasan_depth). All these accesses are > > + * detected by the tool, even though the reports for them are not > > + * printed. > > + * > > + * This is something that might be fixed at some point in the future. > > + */ > > + if (!recover) > > + die("Oops - KHWASAN", regs, 0); > > Why die and not panic? Die seems to be much less used function, and it > calls panic anyway, and we call panic in kasan_report if panic_on_warn > is set. die() is vaguely equivalent to BUG(); die() and BUG() normally only terminate the current process, which may or may not leave the system somewhat usable, while panic() always brings down the whole system. AFAIK panic() shouldn't be used unless you're in some very low-level code where you know that trying to just kill the current process can't work and the entire system is broken beyond repair. If KASAN traps on some random memory access, there's a good chance that just killing the current process will allow at least parts of the system to continue. I'm not sure whether BUG() or die() is more appropriate here, but I think it definitely should not be a panic().
On Wed, Sep 12, 2018 at 7:39 PM, Jann Horn <jannh@google.com> wrote: > On Wed, Sep 12, 2018 at 7:16 PM Dmitry Vyukov <dvyukov@google.com> wrote: >> On Wed, Aug 29, 2018 at 1:35 PM, Andrey Konovalov <andreyknvl@google.com> wrote: > [...] >> > +static int khwasan_handler(struct pt_regs *regs, unsigned int esr) >> > +{ >> > + bool recover = esr & KHWASAN_ESR_RECOVER; >> > + bool write = esr & KHWASAN_ESR_WRITE; >> > + size_t size = KHWASAN_ESR_SIZE(esr); >> > + u64 addr = regs->regs[0]; >> > + u64 pc = regs->pc; >> > + >> > + if (user_mode(regs)) >> > + return DBG_HOOK_ERROR; >> > + >> > + kasan_report(addr, size, write, pc); >> > + >> > + /* >> > + * The instrumentation allows to control whether we can proceed after >> > + * a crash was detected. This is done by passing the -recover flag to >> > + * the compiler. Disabling recovery allows to generate more compact >> > + * code. >> > + * >> > + * Unfortunately disabling recovery doesn't work for the kernel right >> > + * now. KHWASAN reporting is disabled in some contexts (for example when >> > + * the allocator accesses slab object metadata; same is true for KASAN; >> > + * this is controlled by current->kasan_depth). All these accesses are >> > + * detected by the tool, even though the reports for them are not >> > + * printed. >> > + * >> > + * This is something that might be fixed at some point in the future. >> > + */ >> > + if (!recover) >> > + die("Oops - KHWASAN", regs, 0); >> >> Why die and not panic? Die seems to be much less used function, and it >> calls panic anyway, and we call panic in kasan_report if panic_on_warn >> is set. > > die() is vaguely equivalent to BUG(); die() and BUG() normally only > terminate the current process, which may or may not leave the system > somewhat usable, while panic() always brings down the whole system. > AFAIK panic() shouldn't be used unless you're in some very low-level > code where you know that trying to just kill the current process can't > work and the entire system is broken beyond repair. > > If KASAN traps on some random memory access, there's a good chance > that just killing the current process will allow at least parts of the > system to continue. I'm not sure whether BUG() or die() is more > appropriate here, but I think it definitely should not be a panic(). Nick, do you know if die() will be enough to catch problems on Android phones? panic_on_warn would turn this into panic, but I guess one does not want panic_on_warn on a canary phone.
On Thu, Sep 13, 2018 at 1:37 AM Dmitry Vyukov <dvyukov@google.com> wrote: > > On Wed, Sep 12, 2018 at 7:39 PM, Jann Horn <jannh@google.com> wrote: > > On Wed, Sep 12, 2018 at 7:16 PM Dmitry Vyukov <dvyukov@google.com> wrote: > >> On Wed, Aug 29, 2018 at 1:35 PM, Andrey Konovalov <andreyknvl@google.com> wrote: > > [...] > >> > +static int khwasan_handler(struct pt_regs *regs, unsigned int esr) > >> > +{ > >> > + bool recover = esr & KHWASAN_ESR_RECOVER; > >> > + bool write = esr & KHWASAN_ESR_WRITE; > >> > + size_t size = KHWASAN_ESR_SIZE(esr); > >> > + u64 addr = regs->regs[0]; > >> > + u64 pc = regs->pc; > >> > + > >> > + if (user_mode(regs)) > >> > + return DBG_HOOK_ERROR; > >> > + > >> > + kasan_report(addr, size, write, pc); > >> > + > >> > + /* > >> > + * The instrumentation allows to control whether we can proceed after > >> > + * a crash was detected. This is done by passing the -recover flag to > >> > + * the compiler. Disabling recovery allows to generate more compact > >> > + * code. > >> > + * > >> > + * Unfortunately disabling recovery doesn't work for the kernel right > >> > + * now. KHWASAN reporting is disabled in some contexts (for example when > >> > + * the allocator accesses slab object metadata; same is true for KASAN; > >> > + * this is controlled by current->kasan_depth). All these accesses are > >> > + * detected by the tool, even though the reports for them are not > >> > + * printed. > >> > + * > >> > + * This is something that might be fixed at some point in the future. > >> > + */ > >> > + if (!recover) > >> > + die("Oops - KHWASAN", regs, 0); > >> > >> Why die and not panic? Die seems to be much less used function, and it > >> calls panic anyway, and we call panic in kasan_report if panic_on_warn > >> is set. > > > > die() is vaguely equivalent to BUG(); die() and BUG() normally only > > terminate the current process, which may or may not leave the system > > somewhat usable, while panic() always brings down the whole system. > > AFAIK panic() shouldn't be used unless you're in some very low-level > > code where you know that trying to just kill the current process can't > > work and the entire system is broken beyond repair. > > > > If KASAN traps on some random memory access, there's a good chance > > that just killing the current process will allow at least parts of the > > system to continue. I'm not sure whether BUG() or die() is more > > appropriate here, but I think it definitely should not be a panic(). > > > Nick, do you know if die() will be enough to catch problems on Android > phones? panic_on_warn would turn this into panic, but I guess one does > not want panic_on_warn on a canary phone. die() has arch specific implementations, so looking at: arch/arm64/kernel/traps.c:196#die it looks like panic is invoked if in_interrupt() or panic_on_oops(), which is a configure option. So maybe the config for KHWASAN should also enable that? Otherwise seems easy to forget. But maybe that should remain configurable separately? Looking at the kernel configs for the Pixel 2, it does seem like CONFIG_PANIC_ON_OOPS=y is already enabled. https://android.googlesource.com/kernel/msm/+/android-msm-wahoo-4.4-pie/arch/arm64/configs/wahoo_defconfig#746 Specifically to catch problems on Android, our internal debug builds can report on panics, but not oops, IIUC.
On Thu, Sep 13, 2018 at 8:09 PM Nick Desaulniers <ndesaulniers@google.com> wrote: > > On Thu, Sep 13, 2018 at 1:37 AM Dmitry Vyukov <dvyukov@google.com> wrote: > > > > On Wed, Sep 12, 2018 at 7:39 PM, Jann Horn <jannh@google.com> wrote: > > > On Wed, Sep 12, 2018 at 7:16 PM Dmitry Vyukov <dvyukov@google.com> wrote: > > >> On Wed, Aug 29, 2018 at 1:35 PM, Andrey Konovalov <andreyknvl@google.com> wrote: > > > [...] > > >> > +static int khwasan_handler(struct pt_regs *regs, unsigned int esr) > > >> > +{ > > >> > + bool recover = esr & KHWASAN_ESR_RECOVER; > > >> > + bool write = esr & KHWASAN_ESR_WRITE; > > >> > + size_t size = KHWASAN_ESR_SIZE(esr); > > >> > + u64 addr = regs->regs[0]; > > >> > + u64 pc = regs->pc; > > >> > + > > >> > + if (user_mode(regs)) > > >> > + return DBG_HOOK_ERROR; > > >> > + > > >> > + kasan_report(addr, size, write, pc); > > >> > + > > >> > + /* > > >> > + * The instrumentation allows to control whether we can proceed after > > >> > + * a crash was detected. This is done by passing the -recover flag to > > >> > + * the compiler. Disabling recovery allows to generate more compact > > >> > + * code. > > >> > + * > > >> > + * Unfortunately disabling recovery doesn't work for the kernel right > > >> > + * now. KHWASAN reporting is disabled in some contexts (for example when > > >> > + * the allocator accesses slab object metadata; same is true for KASAN; > > >> > + * this is controlled by current->kasan_depth). All these accesses are > > >> > + * detected by the tool, even though the reports for them are not > > >> > + * printed. > > >> > + * > > >> > + * This is something that might be fixed at some point in the future. > > >> > + */ > > >> > + if (!recover) > > >> > + die("Oops - KHWASAN", regs, 0); > > >> > > >> Why die and not panic? Die seems to be much less used function, and it > > >> calls panic anyway, and we call panic in kasan_report if panic_on_warn > > >> is set. > > > > > > die() is vaguely equivalent to BUG(); die() and BUG() normally only > > > terminate the current process, which may or may not leave the system > > > somewhat usable, while panic() always brings down the whole system. > > > AFAIK panic() shouldn't be used unless you're in some very low-level > > > code where you know that trying to just kill the current process can't > > > work and the entire system is broken beyond repair. > > > > > > If KASAN traps on some random memory access, there's a good chance > > > that just killing the current process will allow at least parts of the > > > system to continue. I'm not sure whether BUG() or die() is more > > > appropriate here, but I think it definitely should not be a panic(). > > > > > > Nick, do you know if die() will be enough to catch problems on Android > > phones? panic_on_warn would turn this into panic, but I guess one does > > not want panic_on_warn on a canary phone. > > die() has arch specific implementations, so looking at: > > arch/arm64/kernel/traps.c:196#die > > it looks like panic is invoked if in_interrupt() or panic_on_oops(), > which is a configure option. So maybe the config for KHWASAN should > also enable that? Otherwise seems easy to forget. But maybe that > should remain configurable separately? In the upstream kernel, it is desirable to be able to discover bugs and debug them from inside the running system. When you detect a bug that makes it impossible for the current task to continue safely, you're supposed to use something like BUG() to terminate the task; if you can continue safely, you're supposed to use WARN(). Either way, you should *not* just shoot down the whole kernel unless the system is corrupted so badly that trying to keep running would be pointless. You can configure the kernel such that it crashes the device when such an event occurs, and doing so can sometimes be beneficial; but please don't hardcode such policies into the upstream kernel.
On Thu, Sep 13, 2018 at 8:09 PM, 'Nick Desaulniers' via kasan-dev <kasan-dev@googlegroups.com> wrote: > On Thu, Sep 13, 2018 at 1:37 AM Dmitry Vyukov <dvyukov@google.com> wrote: >> >> On Wed, Sep 12, 2018 at 7:39 PM, Jann Horn <jannh@google.com> wrote: >> > On Wed, Sep 12, 2018 at 7:16 PM Dmitry Vyukov <dvyukov@google.com> wrote: >> >> On Wed, Aug 29, 2018 at 1:35 PM, Andrey Konovalov <andreyknvl@google.com> wrote: >> > [...] >> >> > +static int khwasan_handler(struct pt_regs *regs, unsigned int esr) >> >> > +{ >> >> > + bool recover = esr & KHWASAN_ESR_RECOVER; >> >> > + bool write = esr & KHWASAN_ESR_WRITE; >> >> > + size_t size = KHWASAN_ESR_SIZE(esr); >> >> > + u64 addr = regs->regs[0]; >> >> > + u64 pc = regs->pc; >> >> > + >> >> > + if (user_mode(regs)) >> >> > + return DBG_HOOK_ERROR; >> >> > + >> >> > + kasan_report(addr, size, write, pc); >> >> > + >> >> > + /* >> >> > + * The instrumentation allows to control whether we can proceed after >> >> > + * a crash was detected. This is done by passing the -recover flag to >> >> > + * the compiler. Disabling recovery allows to generate more compact >> >> > + * code. >> >> > + * >> >> > + * Unfortunately disabling recovery doesn't work for the kernel right >> >> > + * now. KHWASAN reporting is disabled in some contexts (for example when >> >> > + * the allocator accesses slab object metadata; same is true for KASAN; >> >> > + * this is controlled by current->kasan_depth). All these accesses are >> >> > + * detected by the tool, even though the reports for them are not >> >> > + * printed. >> >> > + * >> >> > + * This is something that might be fixed at some point in the future. >> >> > + */ >> >> > + if (!recover) >> >> > + die("Oops - KHWASAN", regs, 0); >> >> >> >> Why die and not panic? Die seems to be much less used function, and it >> >> calls panic anyway, and we call panic in kasan_report if panic_on_warn >> >> is set. >> > >> > die() is vaguely equivalent to BUG(); die() and BUG() normally only >> > terminate the current process, which may or may not leave the system >> > somewhat usable, while panic() always brings down the whole system. >> > AFAIK panic() shouldn't be used unless you're in some very low-level >> > code where you know that trying to just kill the current process can't >> > work and the entire system is broken beyond repair. >> > >> > If KASAN traps on some random memory access, there's a good chance >> > that just killing the current process will allow at least parts of the >> > system to continue. I'm not sure whether BUG() or die() is more >> > appropriate here, but I think it definitely should not be a panic(). >> >> >> Nick, do you know if die() will be enough to catch problems on Android >> phones? panic_on_warn would turn this into panic, but I guess one does >> not want panic_on_warn on a canary phone. > > die() has arch specific implementations, so looking at: > > arch/arm64/kernel/traps.c:196#die > > it looks like panic is invoked if in_interrupt() or panic_on_oops(), > which is a configure option. So maybe the config for KHWASAN should > also enable that? Otherwise seems easy to forget. But maybe that > should remain configurable separately? > > Looking at the kernel configs for the Pixel 2, it does seem like > CONFIG_PANIC_ON_OOPS=y is already enabled. > https://android.googlesource.com/kernel/msm/+/android-msm-wahoo-4.4-pie/arch/arm64/configs/wahoo_defconfig#746 Then I think we are good here. > Specifically to catch problems on Android, our internal debug builds > can report on panics, but not oops, IIUC.
On Wed, Sep 12, 2018 at 7:13 PM, Dmitry Vyukov <dvyukov@google.com> wrote: > On Wed, Aug 29, 2018 at 1:35 PM, Andrey Konovalov <andreyknvl@google.com> wrote: >> +static int khwasan_handler(struct pt_regs *regs, unsigned int esr) >> +{ >> + bool recover = esr & KHWASAN_ESR_RECOVER; >> + bool write = esr & KHWASAN_ESR_WRITE; >> + size_t size = KHWASAN_ESR_SIZE(esr); >> + u64 addr = regs->regs[0]; >> + u64 pc = regs->pc; >> + >> + if (user_mode(regs)) >> + return DBG_HOOK_ERROR; >> + >> + kasan_report(addr, size, write, pc); >> + >> + /* >> + * The instrumentation allows to control whether we can proceed after >> + * a crash was detected. This is done by passing the -recover flag to >> + * the compiler. Disabling recovery allows to generate more compact >> + * code. >> + * >> + * Unfortunately disabling recovery doesn't work for the kernel right >> + * now. KHWASAN reporting is disabled in some contexts (for example when >> + * the allocator accesses slab object metadata; same is true for KASAN; >> + * this is controlled by current->kasan_depth). All these accesses are >> + * detected by the tool, even though the reports for them are not >> + * printed. > > > I am not following this part. > Slab accesses metadata. OK. > This is detected as bad access. OK. > Report is not printed. OK. > We skip BRK and resume execution. > What is the problem? When the kernel is compiled with -fsanitize=kernel-hwaddress without any additional flags (like it's done now with KASAN_HW) everything works as you described and there's no problem. However if one were to recompile the kernel with hwasan recovery disabled, KHWASAN wouldn't work due to the reasons described in the comment. Should I make it more clear? > > > >> + * >> + * This is something that might be fixed at some point in the future. >> + */ >> + if (!recover) >> + die("Oops - KHWASAN", regs, 0);
diff --git a/arch/arm64/include/asm/brk-imm.h b/arch/arm64/include/asm/brk-imm.h index ed693c5bcec0..e4a7013321dc 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: KHWASAN 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 KHWASAN_BRK_IMM 0x900 #endif diff --git a/arch/arm64/kernel/traps.c b/arch/arm64/kernel/traps.c index 039e9ff379cc..fd70347d1ce7 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> @@ -269,10 +270,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. @@ -775,7 +780,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); return DBG_HOOK_HANDLED; } @@ -785,6 +790,59 @@ static struct break_hook bug_break_hook = { .fn = bug_handler, }; +#ifdef CONFIG_KASAN_HW + +#define KHWASAN_ESR_RECOVER 0x20 +#define KHWASAN_ESR_WRITE 0x10 +#define KHWASAN_ESR_SIZE_MASK 0x0f +#define KHWASAN_ESR_SIZE(esr) (1 << ((esr) & KHWASAN_ESR_SIZE_MASK)) + +static int khwasan_handler(struct pt_regs *regs, unsigned int esr) +{ + bool recover = esr & KHWASAN_ESR_RECOVER; + bool write = esr & KHWASAN_ESR_WRITE; + size_t size = KHWASAN_ESR_SIZE(esr); + u64 addr = regs->regs[0]; + u64 pc = regs->pc; + + if (user_mode(regs)) + return DBG_HOOK_ERROR; + + kasan_report(addr, size, write, pc); + + /* + * The instrumentation allows to control whether we can proceed after + * a crash was detected. This is done by passing the -recover flag to + * the compiler. Disabling recovery allows to generate more compact + * code. + * + * Unfortunately disabling recovery doesn't work for the kernel right + * now. KHWASAN reporting is disabled in some contexts (for example when + * the allocator accesses slab object metadata; same is true for KASAN; + * this is controlled by current->kasan_depth). All these accesses are + * detected by the tool, even though the reports for them are not + * printed. + * + * This is something that might be fixed at some point in the future. + */ + if (!recover) + die("Oops - KHWASAN", regs, 0); + + /* If thread survives, skip over the brk instruction and continue: */ + __arm64_skip_faulting_instruction(regs, AARCH64_INSN_SIZE); + return DBG_HOOK_HANDLED; +} + +#define KHWASAN_ESR_VAL (0xf2000000 | KHWASAN_BRK_IMM) +#define KHWASAN_ESR_MASK 0xffffff00 + +static struct break_hook khwasan_break_hook = { + .esr_val = KHWASAN_ESR_VAL, + .esr_mask = KHWASAN_ESR_MASK, + .fn = khwasan_handler, +}; +#endif + /* * Initial handler for AArch64 BRK exceptions * This handler only used until debug_traps_init(). @@ -792,6 +850,10 @@ static struct break_hook bug_break_hook = { int __init early_brk64(unsigned long addr, unsigned int esr, struct pt_regs *regs) { +#ifdef CONFIG_KASAN_HW + if ((esr & KHWASAN_ESR_MASK) == KHWASAN_ESR_VAL) + return khwasan_handler(regs, esr) != DBG_HOOK_HANDLED; +#endif return bug_handler(regs, esr) != DBG_HOOK_HANDLED; } @@ -799,4 +861,7 @@ int __init early_brk64(unsigned long addr, unsigned int esr, void __init trap_init(void) { register_break_hook(&bug_break_hook); +#ifdef CONFIG_KASAN_HW + register_break_hook(&khwasan_break_hook); +#endif }
KHWASAN 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 add a KHWASAN 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. Signed-off-by: Andrey Konovalov <andreyknvl@google.com> --- arch/arm64/include/asm/brk-imm.h | 2 + arch/arm64/kernel/traps.c | 69 +++++++++++++++++++++++++++++++- 2 files changed, 69 insertions(+), 2 deletions(-)