All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jann Horn <jannh@google.com>
To: Dmitry Vyukov <dvyukov@google.com>
Cc: Andrey Konovalov <andreyknvl@google.com>,
	Andrey Ryabinin <aryabinin@virtuozzo.com>,
	Alexander Potapenko <glider@google.com>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will.deacon@arm.com>,
	Christoph Lameter <cl@linux.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Mark Rutland <mark.rutland@arm.com>,
	Nick Desaulniers <ndesaulniers@google.com>,
	Marc Zyngier <marc.zyngier@arm.com>,
	dave.martin@arm.com, Ard Biesheuvel <ard.biesheuvel@linaro.org>,
	"Eric W. Biederman" <ebiederm@xmission.com>,
	Ingo Molnar <mingo@kernel.org>,
	Paul Lawrence <paullawrence@google.com>,
	geert@linux-m68k.org, Arnd Bergmann <arnd@arndb.de>,
	"Kirill A . Shutemov" <kirill.shutemov@linux.intel.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	kstewart@linuxfoundation.org,
	Mike Rapoport <rppt@linux.vnet.ibm.com>,
	kasan-dev@googlegroups.com, linux-doc@vger.kernel.org,
	kernel list <linux-kernel@vger.kernel.org>,
	linux-arm-kernel@lists.infradead.org,
	linux-sparse@vger.kernel.org, Linux-MM <linux-mm@kvack.org>,
	linux-kbuild@vger.kernel.org, Kostya Serebryany <kcc@google.com>,
	Evgenii Stepanov <eugenis@google.com>,
	Lee.Smith@arm.com, Ramana.Radhakrishnan@arm.com,
	Jacob.Bramley@arm.com, Ruben.Ayrapetyan@arm.com,
	Mark Brand <markbrand@google.com>,
	cpandya@codeaurora.org, Vishwath Mohan <vishwath@google.com>
Subject: Re: [PATCH v6 15/18] khwasan, arm64: add brk handler for inline instrumentation
Date: Wed, 12 Sep 2018 19:39:30 +0200	[thread overview]
Message-ID: <CAG48ez2oT1dtDcH8SfPLnoX5F8d6Pd=M-eOKHhYJ83EuL_j6wQ@mail.gmail.com> (raw)
In-Reply-To: <CACT4Y+aEwYiaVN--RH_0VBh0wbCcrf-Ndz+_eOaBNi6nKxrfQA@mail.gmail.com>

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().

WARNING: multiple messages have this Message-ID (diff)
From: Jann Horn <jannh@google.com>
To: Dmitry Vyukov <dvyukov@google.com>
Cc: Andrey Konovalov <andreyknvl@google.com>,
	Andrey Ryabinin <aryabinin@virtuozzo.com>,
	Alexander Potapenko <glider@google.com>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will.deacon@arm.com>,
	Christoph Lameter <cl@linux.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Mark Rutland <mark.rutland@arm.com>,
	Nick Desaulniers <ndesaulniers@google.com>,
	Marc Zyngier <marc.zyngier@arm.com>,
	dave.martin@arm.com, Ard Biesheuvel <ard.biesheuvel@linaro.org>,
	"Eric W. Biederman" <ebiederm@xmission.com>,
	Ingo Molnar <mingo@kernel.org>,
	Paul Lawrence <paullawrence@google.com>,
	geert@linux-m68k.org, Arnd Bergmann <arnd@arndb.de>,
	"Kirill A . Shutemov" <kirill.shutemov@linux.intel.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	kstewart@linuxfound
Subject: Re: [PATCH v6 15/18] khwasan, arm64: add brk handler for inline instrumentation
Date: Wed, 12 Sep 2018 19:39:30 +0200	[thread overview]
Message-ID: <CAG48ez2oT1dtDcH8SfPLnoX5F8d6Pd=M-eOKHhYJ83EuL_j6wQ@mail.gmail.com> (raw)
In-Reply-To: <CACT4Y+aEwYiaVN--RH_0VBh0wbCcrf-Ndz+_eOaBNi6nKxrfQA@mail.gmail.com>

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().

WARNING: multiple messages have this Message-ID (diff)
From: jannh@google.com (Jann Horn)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v6 15/18] khwasan, arm64: add brk handler for inline instrumentation
Date: Wed, 12 Sep 2018 19:39:30 +0200	[thread overview]
Message-ID: <CAG48ez2oT1dtDcH8SfPLnoX5F8d6Pd=M-eOKHhYJ83EuL_j6wQ@mail.gmail.com> (raw)
In-Reply-To: <CACT4Y+aEwYiaVN--RH_0VBh0wbCcrf-Ndz+_eOaBNi6nKxrfQA@mail.gmail.com>

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().

  reply	other threads:[~2018-09-12 17:40 UTC|newest]

Thread overview: 148+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-08-29 11:35 [PATCH v6 00/18] khwasan: kernel hardware assisted address sanitizer Andrey Konovalov
2018-08-29 11:35 ` Andrey Konovalov
2018-08-29 11:35 ` Andrey Konovalov
2018-08-29 11:35 ` [PATCH v6 01/18] khwasan, mm: change kasan hooks signatures Andrey Konovalov
2018-08-29 11:35   ` Andrey Konovalov
2018-08-29 11:35 ` [PATCH v6 02/18] khwasan: move common kasan and khwasan code to common.c Andrey Konovalov
2018-08-29 11:35   ` Andrey Konovalov
2018-08-29 11:35 ` [PATCH v6 03/18] khwasan: add CONFIG_KASAN_GENERIC and CONFIG_KASAN_HW Andrey Konovalov
2018-08-29 11:35   ` Andrey Konovalov
2018-09-12 14:47   ` Dmitry Vyukov
2018-09-12 14:47     ` Dmitry Vyukov
2018-09-12 14:47     ` Dmitry Vyukov
2018-09-12 14:51     ` Dmitry Vyukov
2018-09-12 14:51       ` Dmitry Vyukov
2018-09-12 14:51       ` Dmitry Vyukov
2018-09-17 18:42     ` Andrey Konovalov
2018-09-17 18:42       ` Andrey Konovalov
2018-09-17 18:42       ` Andrey Konovalov
2018-08-29 11:35 ` [PATCH v6 04/18] khwasan, arm64: adjust shadow size for CONFIG_KASAN_HW Andrey Konovalov
2018-08-29 11:35   ` Andrey Konovalov
2018-09-12 14:54   ` Dmitry Vyukov
2018-09-12 14:54     ` Dmitry Vyukov
2018-09-12 14:54     ` Dmitry Vyukov
2018-09-19 17:27     ` Andrey Konovalov
2018-09-19 17:27       ` Andrey Konovalov
2018-09-19 17:27       ` Andrey Konovalov
2018-08-29 11:35 ` [PATCH v6 05/18] khwasan: initialize shadow to 0xff Andrey Konovalov
2018-08-29 11:35   ` Andrey Konovalov
2018-08-29 11:35 ` [PATCH v6 06/18] khwasan, arm64: untag virt address in __kimg_to_phys and _virt_addr_is_linear Andrey Konovalov
2018-08-29 11:35   ` Andrey Konovalov
2018-09-12 16:33   ` Dmitry Vyukov
2018-09-12 16:33     ` Dmitry Vyukov
2018-09-12 16:33     ` Dmitry Vyukov
2018-09-18 17:09     ` Andrey Konovalov
2018-09-18 17:09       ` Andrey Konovalov
2018-09-18 17:09       ` Andrey Konovalov
2018-08-29 11:35 ` [PATCH v6 07/18] khwasan: add tag related helper functions Andrey Konovalov
2018-08-29 11:35   ` Andrey Konovalov
2018-08-29 11:35   ` Andrey Konovalov
2018-09-12 16:21   ` Dmitry Vyukov
2018-09-12 16:21     ` Dmitry Vyukov
2018-09-12 16:21     ` Dmitry Vyukov
2018-09-17 18:59     ` Andrey Konovalov
2018-09-17 18:59       ` Andrey Konovalov
2018-09-17 18:59       ` Andrey Konovalov
2018-09-18 15:45       ` Dmitry Vyukov
2018-09-18 15:45         ` Dmitry Vyukov
2018-09-18 15:45         ` Dmitry Vyukov
2018-08-29 11:35 ` [PATCH v6 08/18] khwasan: preassign tags to objects with ctors or SLAB_TYPESAFE_BY_RCU Andrey Konovalov
2018-08-29 11:35   ` Andrey Konovalov
2018-09-04 15:17   ` Christopher Lameter
2018-09-12 16:36   ` Dmitry Vyukov
2018-09-12 16:36     ` Dmitry Vyukov
2018-09-12 16:36     ` Dmitry Vyukov
2018-09-18 16:50     ` Andrey Konovalov
2018-09-18 16:50       ` Andrey Konovalov
2018-09-18 16:50       ` Andrey Konovalov
2018-08-29 11:35 ` [PATCH v6 09/18] khwasan, arm64: fix up fault handling logic Andrey Konovalov
2018-08-29 11:35   ` Andrey Konovalov
2018-08-29 11:35 ` [PATCH v6 10/18] khwasan, arm64: enable top byte ignore for the kernel Andrey Konovalov
2018-08-29 11:35   ` Andrey Konovalov
2018-08-29 11:35 ` [PATCH v6 11/18] khwasan, mm: perform untagged pointers comparison in krealloc Andrey Konovalov
2018-08-29 11:35   ` Andrey Konovalov
2018-09-04 15:18   ` Christopher Lameter
2018-08-29 11:35 ` [PATCH v6 12/18] khwasan: split out kasan_report.c from report.c Andrey Konovalov
2018-08-29 11:35   ` Andrey Konovalov
2018-08-29 11:35 ` [PATCH v6 13/18] khwasan: add bug reporting routines Andrey Konovalov
2018-08-29 11:35   ` Andrey Konovalov
2018-09-12 17:50   ` Dmitry Vyukov
2018-09-12 17:50     ` Dmitry Vyukov
2018-09-12 17:50     ` Dmitry Vyukov
2018-09-18 17:36     ` Andrey Konovalov
2018-09-18 17:36       ` Andrey Konovalov
2018-09-18 17:36       ` Andrey Konovalov
2018-08-29 11:35 ` [PATCH v6 14/18] khwasan: add hooks implementation Andrey Konovalov
2018-08-29 11:35   ` Andrey Konovalov
2018-09-12 18:30   ` Dmitry Vyukov
2018-09-12 18:30     ` Dmitry Vyukov
2018-09-12 18:30     ` Dmitry Vyukov
2018-09-19 11:54     ` Andrey Konovalov
2018-09-19 11:54       ` Andrey Konovalov
2018-09-19 11:54       ` Andrey Konovalov
2018-08-29 11:35 ` [PATCH v6 15/18] khwasan, arm64: add brk handler for inline instrumentation Andrey Konovalov
2018-08-29 11:35   ` Andrey Konovalov
2018-09-12 17:13   ` Dmitry Vyukov
2018-09-12 17:13     ` Dmitry Vyukov
2018-09-12 17:13     ` Dmitry Vyukov
2018-09-17 19:12     ` Andrey Konovalov
2018-09-17 19:12       ` Andrey Konovalov
2018-09-17 19:12       ` Andrey Konovalov
2018-09-12 17:15   ` Dmitry Vyukov
2018-09-12 17:15     ` Dmitry Vyukov
2018-09-12 17:15     ` Dmitry Vyukov
2018-09-12 17:39     ` Jann Horn [this message]
2018-09-12 17:39       ` Jann Horn
2018-09-12 17:39       ` Jann Horn
2018-09-13  8:37       ` Dmitry Vyukov
2018-09-13  8:37         ` Dmitry Vyukov
2018-09-13  8:37         ` Dmitry Vyukov
2018-09-13 18:09         ` Nick Desaulniers
2018-09-13 18:09           ` Nick Desaulniers
2018-09-13 18:09           ` Nick Desaulniers
2018-09-13 18:23           ` Jann Horn
2018-09-13 18:23             ` Jann Horn
2018-09-13 18:23             ` Jann Horn
2018-09-14  5:11           ` Dmitry Vyukov
2018-09-14  5:11             ` Dmitry Vyukov
2018-09-14  5:11             ` Dmitry Vyukov
2018-08-29 11:35 ` [PATCH v6 16/18] khwasan, mm, arm64: tag non slab memory allocated via pagealloc Andrey Konovalov
2018-08-29 11:35   ` Andrey Konovalov
2018-09-07 16:06   ` Andrey Ryabinin
2018-09-07 16:06     ` Andrey Ryabinin
2018-09-11 16:10     ` Andrey Konovalov
2018-09-11 16:10       ` Andrey Konovalov
2018-09-11 16:10       ` Andrey Konovalov
2018-08-29 11:35 ` [PATCH v6 17/18] khwasan: update kasan documentation Andrey Konovalov
2018-08-29 11:35   ` Andrey Konovalov
2018-09-12 18:39   ` Dmitry Vyukov
2018-09-12 18:39     ` Dmitry Vyukov
2018-09-12 18:39     ` Dmitry Vyukov
2018-09-18 18:42     ` Andrey Konovalov
2018-09-18 18:42       ` Andrey Konovalov
2018-09-18 18:42       ` Andrey Konovalov
2018-08-29 11:35 ` [PATCH v6 18/18] kasan: add SPDX-License-Identifier mark to source files Andrey Konovalov
2018-08-29 11:35   ` Andrey Konovalov
2018-09-05 21:10 ` [PATCH v6 00/18] khwasan: kernel hardware assisted address sanitizer Andrew Morton
2018-09-05 21:10   ` Andrew Morton
2018-09-05 21:10   ` Andrew Morton
2018-09-05 21:55   ` Nick Desaulniers
2018-09-05 21:55     ` Nick Desaulniers
2018-09-05 21:55     ` Nick Desaulniers
2018-09-06 10:05   ` Will Deacon
2018-09-06 10:05     ` Will Deacon
2018-09-06 10:05     ` Will Deacon
2018-09-06 11:06     ` Andrey Konovalov
2018-09-06 11:06       ` Andrey Konovalov
2018-09-06 11:06       ` Andrey Konovalov
2018-09-06 16:39       ` Nick Desaulniers
2018-09-06 16:39         ` Nick Desaulniers
2018-09-06 16:39         ` Nick Desaulniers
2018-09-14 15:28       ` Will Deacon
2018-09-14 15:28         ` Will Deacon
2018-09-14 15:28         ` Will Deacon
2018-09-19 18:53         ` Andrey Konovalov
2018-09-19 18:53           ` Andrey Konovalov
2018-09-19 18:53           ` Andrey Konovalov
2018-09-07 16:10 ` Andrey Ryabinin
2018-09-07 16:10   ` Andrey Ryabinin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAG48ez2oT1dtDcH8SfPLnoX5F8d6Pd=M-eOKHhYJ83EuL_j6wQ@mail.gmail.com' \
    --to=jannh@google.com \
    --cc=Jacob.Bramley@arm.com \
    --cc=Lee.Smith@arm.com \
    --cc=Ramana.Radhakrishnan@arm.com \
    --cc=Ruben.Ayrapetyan@arm.com \
    --cc=akpm@linux-foundation.org \
    --cc=andreyknvl@google.com \
    --cc=ard.biesheuvel@linaro.org \
    --cc=arnd@arndb.de \
    --cc=aryabinin@virtuozzo.com \
    --cc=catalin.marinas@arm.com \
    --cc=cl@linux.com \
    --cc=cpandya@codeaurora.org \
    --cc=dave.martin@arm.com \
    --cc=dvyukov@google.com \
    --cc=ebiederm@xmission.com \
    --cc=eugenis@google.com \
    --cc=geert@linux-m68k.org \
    --cc=glider@google.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=kasan-dev@googlegroups.com \
    --cc=kcc@google.com \
    --cc=kirill.shutemov@linux.intel.com \
    --cc=kstewart@linuxfoundation.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kbuild@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linux-sparse@vger.kernel.org \
    --cc=marc.zyngier@arm.com \
    --cc=mark.rutland@arm.com \
    --cc=markbrand@google.com \
    --cc=mingo@kernel.org \
    --cc=ndesaulniers@google.com \
    --cc=paullawrence@google.com \
    --cc=rppt@linux.vnet.ibm.com \
    --cc=vishwath@google.com \
    --cc=will.deacon@arm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.