On Wed, Sep 12, 2018 at 7:13 PM, Dmitry Vyukov <dvyukov@xxxxxxxxxx> wrote:
> On Wed, Aug 29, 2018 at 1:35 PM, Andrey Konovalov <andreyknvl@xxxxxxxxxx> 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);
